"To Do" and "Memento" List
==========================
CVS: $Header: /cvsroot/pantomime/PantoMIME/doc/todo.txt,v 1.31 2002/04/12 11:06:49 menelan Exp $

* General:
   * Currently, if a mail is parsed and extracted, some information has been lost.
     E.g. comments. Is this acceptable? (If not we need to mend parser rules; currently,
     the lexer strips comments so they don't interfere with the parser grammar).
   * Groups: currently we don't have any model counterpart of groups in address fields... :-?
   * If messages are parsed directly from an IReader on construction, users don't
     get a chance to register themselves as supervisors of the message...
   * See if the static_cast<> protected extension of ISupervisor/ISupervised trick can be reestablished.
   * Deferred extraction of parts should be optional; configured from message configurator.
     (If you parse directly from a socket, for instance, you won't be able to seek back later to extract data.)
     Perhaps a threshold for when to defer should be user configurable?
   * Readers cannot be copied but messages can - what to do when messages are used deferred reading?

* Header & Fields:
   * Fields are now IExtractable.
     However, maybe IHeader should do the ICharset/ITransferEncoding transcoding?
     Or implement in common realisation base, perhaps?
     If Fields transcode themselves, they should be ISupervised so they can throw warnings...
     (IHeader would need to extend ISupervisor also, then, to be able to relay warnings...)

* Transcoding:
   * Even in US-ASCII, not all characters may appear in email headers (also see section 4 of RFC2047).
   * 7/8-Bit encodings should make hard line breaks to enforce max. line length limit.
   * Transcoder names are case insensitive; should they return names in lower-case always, to ease comparison?

* Parser:
   * Try to add beter error recovery. Currently we restart at each field, but it should
     be possible to e.g. restart after each ',' separator in lists, etc.
   * Upgrade to support MIME extensions.
   * The "obsolete" RFC-2822 syntax is currently not handled...

* Exceptions:
   * Some global level PantoMIME error code should probably be incorporated.
     That way clients can know what error to report to users; the exception
     error text is only intended as an aid for developers.

* Thread Safety:
   * We haven't really addresses this issue. It's difficult because we want
     PantoMIME to be independent of specific semaphore implementations;
     on the other hand, retrofitting thread safety can be difficult...
     Maybe a simple mutex interface that ppl can implement if they need?