Drop todo.txt - moved to http://botan.randombit.net/todo.html

1 files changed, 0 insertions, 160 deletions

diff --git a/doc/todo.txt b/doc/todo.txt
deleted file mode 100644
index e7eb34d88..000000000
--- a/doc/todo.txt
+++ /dev/null
@@ -1,160 +0,0 @@
-
-There are many areas where Botan is deficient. This file documents
-some of the more interesting ones. If you're thinking about working on
-something within Botan, one of these areas might be a good place to
-start. Questions or comments can go to the development mailing list.
-
-Build System / Porting
---------------------
-
-The new configure script is fairly flexible in terms of build systems
-(though there do remain a few pieces of code tied to the idea of
-make-style syntax). No doubt many users would appreciate having Botan
-well-integrated into their build environment, so patches to
-configure.pl (and new template files for misc/config/makefile/) to add
-support for other build systems. The most requested by far is Visual
-Studio project files; others that might be of interest would be
-autotools, Scons, CMake, and jam/bjam.
-
-Testing the configure/build/install steps on as many platforms and
-compilers as possible is a huge win for us. Builds on some platforms,
-like the Motorola 680x0 and Hitachi SH machines, IBM's AIX on any CPU
-type, and the Haiku operating system (a BeOS R5 clone) - have *never*
-been attempted; the support is based entirely on documentation and
-conjecture, and is very unlikely to work. Support for several
-operating systems is completely nonexistent - this class includes VMS,
-vxWorks, eCos, MINIX, GNU/Hurd, L4, and Coyotos. Others, like IRIX,
-HP-UX, QNX, and Tru64, are tested only very rarely. Similarly, many
-commercial compilers are only tested occasionally.
-
-Setting up a buildbot system would be ideal, if access to enough
-machines can be arranged (for the x86 and amd64 operating systems, a
-single machine running Xen or VMware could suffice). Even one-shot
-tests with the latest sources on a variety of machines would be
-incredibly useful.
-
-A nice but not essential feature for configure.pl would be adding the
-ability to generate any needed or requested package-building scripts,
-with support for systems like rpm, portage, dpkg, commercial Unix
-package systems, and Windows installer systems.
-
-Splitting the build into distinct static and shared targets (and
-static-debug and shared-debug) would make certain things much simpler,
-as well as being a performance advantage on many systems (in
-particular on x86, where losing %ebx for the PIC pointer is a huge
-loss)
-
-Modules to allow use of platform-specific features within Botan can
-make life significantly better for users on that platform. Generic
-Unix/POSIX support is more or less complete, but there are countless
-vendor extensions that might be used in Botan in interesting and
-useful ways. Windows has the basics (two entropy source modules, and
-modules giving access to mutexes and high resolution timers), but
-there are probably a number of interesting extensions one could write,
-like making Botan's objects callable by DCOM. Other systems probably
-have all kinds of interesting system and library calls we can use.
-
-Self-test / Benchmark System
---------------------
-
-The code is not terrible, but it is significantly sloppier than the
-library code it is testing. Reporting should be generalized and
-encapsulated, so it can easily be extended to produce tests results as
-text to the terminal, or HTML with full details, or as an email, or
-any of a number of useful formats (which would provide a varying
-amount of information about what was tested and what went wrong).
-Bonus points for writing a general system that takes in an arbitrary
-'template' file and outputs the filled out report.
-
-Much of the code operates at a very low level of abstraction; this has
-caused it to be difficult to add tests that vary much from the simple
-known answer tests used for the ciphers and hashes.
-
-All of the simple functions (rotate_left, get_byte, etc) should be
-tested (a failure in one of these causes many failures later, which
-are harder to diagnose).
-
-There are significant codepaths that have no tests written for them,
-particularly in the X.509 certificate processing code.
-
-The benchmark code should also have its output formats generalized; it
-would be pretty great to have a benchmark run produce a detailed
-report as HTML and some gnuplot datasets to generate the images
-included from the HTML file.
-
-New Memory Allocator
---------------------
-
-The current pool allocator is serviceable but it can be very wasteful
-of memory and could easily be several times faster. Someone who is
-interested in algorithms might enjoy working on this.
-
-Documentation
---------------------
-
-This could occupy someone for months. Perhaps even a majority of the
-API is undocumented, and while these are the less important pieces (or
-at least pieces meant mostly for internal library use), it would be
-great to have at least a brief description of each of them, along with
-a pointer to the appropriate headers. Text written in either a
-tutorial style or as a straight API breakdown could easily be
-integrated.
-
-There are many obvious example programs which have yet to be written,
-including encrypting a file with a shared passphrase, and securely
-salting and hashing a password for storage. Check the mailing list
-archives for ideas.
-
-Public Key Engines
---------------------
-
-In addition to the fairly low level BigInt optimizations that remain
-to be done, Botan provides a plugin system that allows different
-implementations of entire algorithms (RSA, DSA, etc) to be included,
-which can then be used in a completely transparent manner by
-application code. As of this writing one hardware public key
-accelerator (AEP's SureWare Runner cards) and two software backends
-(GNU MP and OpenSSL's BN library) are supported. There are many others
-out there, including Apple's vBigNum AltiVec library, Intel's
-Performance Primitives library, OpenBSD's /dev/crypto, and hardware
-units like the Broadcom BCM582x and Hi/fn 6500.
-
-BigInt
---------------------
-
-The portable BigInt routines are fairly good, and as of 1.6 we're
-using reasonably good algorithms. But well written assembly can often
-speed up public key operations by 50% or more. There currently exists
-some limited x86 and x86-64 assembly, but implementations for other
-architectures (such as Cell's SPU units, PowerPC, SPARCv9, MIPS, and
-ARM) could really help, as could further work on the x86 code
-(including making use of SSE instructions and VIA's Montgomery
-multiplication instruction). The key routines for good performance are
-bigint_monty_redc and bigint_simple_sqr; together they make up 30-60%
-of the runtime of most public key algorithms.
-
-It is very likely that many of the core algorithms (in src/mp_*) could
-be optimized at the C level by anyone has some knowledge or interest
-in algorithms.
-
-Compression Modules
---------------------
-
-Botan currently supports the bzip2 and zlib compression
-formats. Support for gzip and (less importantly) zip would likely be
-appreciated by many users. There are also other interesting algorithms
-such as LZO (supposedly very fast, which might make it useful in
-custom network protocols), and LZW (a compression algorithm patented
-by nCipher; they sell hardware implementations).
-
-X.509 Attribute Certificates
---------------------
-
-Most of the low-level processing code needed, like support for the
-ASN.1 SIGNED macro and the DER/BER codec, have already been written
-and used sufficiently to be well tested and relatively easy to work
-with. However it involves a lot of careful coding and design work to
-deal with the semantic issues and provide a good interface to the
-user; at this point I don't have the slightest idea what a useful API
-for attribute certificates would be like. RFC 3281 and its references
-have most of the information you'll need.