Re: [Evolution-hackers] There's no need to be so hard on iconv

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2007-10-11 at 10:52 -0400, Jeffrey Stedfast wrote:
> I have far better fixes in GMime that need to be ported to Camel.
> 

Porting GMime to Camel would be an interesting effort indeed. Perhaps
just replacing CamelMimePart with GMime.

I noticed that CamelMimePart it not 'very' glued to the providers of
Camel. Mostly parsing either TOP or something that you receive from the
IMAP server that looks like a TOP into a CamelMessageInfo and through
the CamelDataCache (or the one that is specific for IMAP) getting a
stream that will be passed to CamelMimePart's infrastructure.

That's just two glue points to cut and replace with new ones.

However, my actual goal is to marry the mime parser a lot more with the
service:

o. Modern IMAP servers will have the CATENATE capability for composing a
   message at the IMAP server (Lemonade's forward without download
   feature). Although this is something very few actual IMAP servers in
   the field have correctly configured right now, and therefore it does
   not have a very high priority for me).

o. Retrieving the parts the first time they are streamed to a target
   (like a file-stream or the HTML component), while a decoding stream
   sits in the middle or not, rather than always when a message is
   requested, would be very interesting for networks where consuming
   bandwidth is expensive and devices where local storage is limited.

   Right now I call this 'partial message retrieval'. What I would
   really want would be retrieving any part of the message on-demand and
   initially only storing the BODYSTRUCTURE and the summary item
   locally (and as parts get requested, caching them individually).

   This is, afaik, a major rewrite and rethinking of CamelMimePart vs.
   CamelStore and CamelFolder and why I think even spruce and the new
   IMAP4 provider are not yet what I think is what we'll in future
   need. Although I'm also fine with pragmatism and pragmatic goals. I
   also understand that right now only a limited amount of IMAP servers
   would cope with this method and that for a lot of servers an
   old-style of using the service would be needed.

o. The CONVERT capability (that is not even specified yet) which will
   make it possible for an E-mail client to ask the IMAP server for a
   converted version of a MIME part. For example if the image is too
   large for the bandwidth and display of the device, the client could
   ask for a converted version of it. 

   Another example would be converting a Word document to a antiword
   like text version of the Word document, serverside, in stead of
   having to deploy a bunch of Word-format reading code on your
   cellphone and retrieve the entire document.

These three things mean that what I would really like, might not be
compatible with what GMime's (current) purpose is (I think GMime is more
about parsing it than also having control over the retrieval of the
parts, dealing with BODYSTRUCTURE rather than parsing from the actual
content, etc etc). GMime, right now, is 'very' interesting if you
already have the entire contents of the E-mail (like, serverside).

Although with some adaptations you can make these three work with what
CamelMimePart and/or GMime are too (no need to convince me of that). It
might, however, not be as ideal or harder this way.

Anyway, just thoughts...


-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog