[no subject]

The last couple of days I made some big changes to the internals
of the mime-message and friends.  First, the camel-medium
now stores all headers 'all the time'.  So for example when
you do mime_message_set_from() it sets up the From header
in the camel-medium.  This is more consistent use of the
object I think.  Also, api's like set_subject() now accept
UTF-8 strings.  When they set the actual subject header in
the camel-medium they perform the rfc2047 style encoding, so
the camel-medium headers are always in a consistent and
writable state.  So the idea is that all api's at the message/part
level work in the native format of the calling environment (i.e
unicode strings, and time_t dates, etc), and all the api's
at the medium level work in the native format of the target
environment (i.e. mime messages).  I removed some of the weird
indirection used to handle header change snooping so it is
now simpler and easier to follow.  You can also set multitiple headers
for headers that can be set multiple times.  I also
got the mime-message and friends to build from a parser.
This makes a big difference, makes the code a lot more
simpler, and a lot more obvious, and uses object inheritence
and overriding better than it did before, although there's
still more to do.  As a plus you can now create a mime message
from a non-seekable stream (it will automagically cache
the contents in memory).

The short is that now the message browser is a lot lot faster
(like, possibly orders of magnitude faster to browse a big
message with attachments).  And it displays more messages
more correctly (althogh not everything - yet).

Other useful things - I have a new class type CamelMimeFilter
which can be used to implement conversion filters that
take an input buffer and do something with it, and provide
and output buffer.  They are chainable, and they dont
work on copying data (like the camel-streams have to
to do the same thing), so they are *fast*, they are also
a lot easier to write and smaller than a stream.  They can be
attached to the camel-mime-parser as its decoding body data,
or you can attach them to another stream CamelStreamFilter
to convert streams on the fly.   This allows the summary
generator to just attach a decoder, charset converter and
indexer to the mime parser as it parses the message content
to automatically index text parts in unicode.

I think thats about it so far ...

Fortunately I dont think any of the changes so far have reduced
the stability, although they haven't really added to it yet either.

My todo list seems to be growing, but so far I have these things
planned:

 - finish off the create_from_parser stuff, move a little code
   into mime-message (trivial).  And probably get rid of the
   create_from_stream virtual method (but provide a helper function
   to do this).  Remove the data wrapper repository - it
   doesn't really serve any real use (it can be replaced by
   a 3 line switch statement ...).  Remove lots of other dead
   code.
 - Create an address type, where you have a "real name" and an
   "address spec" part, do the code to parse a raw address
   list into this type of address (the code is there, it just
   discards the results so far).  Change the address api's
   to accept/return these types.  Possibly allow/store
   "group" address specifications (it already parses them).
   Finally remove the last virtual methods in camel-mime-message.
 - Finish/recheck the message header api's for
   consistency/completeness. 
 - Do something about the 'set input stream' 'create from stream'
   ambiguity.  The api's are going toward synchronous operation.
   To get asynchronous operation threads are to be used - the
   async api's are just too complicated to implement reliably
   (to put it bluntly).
 - Add the rest of the rfc822 headers to camel-mime-message (it
   currently misses out a lot).
 - Do rfc2047 for structured fields as well (e.g. phrases in From:).
 - Better selection of charsets for rfc2047 encoding (it
   only does us-ascii, iso-8859-1 and utf-8 at the moment).
 - Probably, move most of the guts of the camel-mbox-search into
   a new class camel-folder-search which has virtual methods
   for all of the match operations i.e. so most of the guts of 
   the search can be implemented in 1 place, and shared among
   providers.  IMAP will just override almost every method ...
 - Do something about message flags.  What is there doesn't do
   anything, and is probably hard to implement/use.
 - Add signals to messages and folders so folders and interested
   parties can track things like changed flags, new messages, etc.
 - Clean up the folder object/api (as outlined in a previous post).
 - Make mbox a lot more robust.
 - Actually finish the mbox provider.
 - Make the mbox summary a little more robust.
 - A lot of cleanup and api documentation.  A lot of code is
   being obsoleted by new code.
 - Some sort of test suite to exercise everything.

Pie in the sky's:
 - Threading issues.

 Michael