Re: Patch: set of fixes for Bodystruct backend

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2009-12-10 at 11:38 +0100, José Dapena Paz wrote:
> El dom, 06-12-2009 a las 14:41 +0100, Philip Van Hoof escribió:
> > Hey José,
> > 
> > Awesome that you guys are finally picking up the bodystruct work.
> > 
> > Will you also change the summary fetch in the IMAP4 code to only fetch
> > ENVELOPE and BODYSTRUCT, and then immediately make the BODYSTRUCT pieces
> > available in the caches? Right now the code for turning a chunk of IMAP
> > reply into a CamelMessageInfo only eats raw headers, and not ENVELOPE.
> > And for the BODYSTRUCT part you'd just need to save that part as a
> > filename in the caches (to be compatible with the support that you are
> > hacking on right now).
> 
> 	:) Not... now. It's a goal I personally want to reach, but the part I
> was needing was using bodystruct for supporting retrieval of only the
> desired mime parts. And for doing this, I chose the option that's more
> close to the ideal point (first bodystruct then envelope, instead of
> trying to fix that partial message retrieve strategy :).

Sure, of course.

Per MIME part fetch, as you know, was the thing I always pushed for at
Modest back when I was on the team. I think this is very important for a
good user experience with low bandwidth utilization (don't download huge
photograph attachments of such E-mails unless the user wants them, etc).

But you still want to find meta information about that attachment as
early as possible (filename, exif tags?, size, mime-type, etc)

Ideally stuffing it into an RDF store like tracker-store (which will be
available on Harmattan, and even play a central role for metadata).

Now apps can tag this attachment-resource, make relationships with it,
search for it, browse to it, even before it was ever downloaded to the
device. And this instantly at synchronization of the IMAP mailbox.

Without using much bandwidth at all.

If Modest would during its synchronization also fetch MIME part 1 or
MIME part 1.1 (based on the layout of the bodystructure), you'd have all
the text/plain MIME parts. Pass the content of that as the property
nie:plainTextContent of nmo:Email in RDF, and suddenly you have full
text search over SPARQL (the default metadata query infrastructure for
Harmattan) for all your E-mails.

http://live.gnome.org/Tracker/Documentation/Examples/SPARQL/Email

You should check whether the SSL library that you link Tinymail against
for Modest (I think that's Mozilla's NSS) does TLS compression. If the
IMAP server also has the right SSL library, then pumping ALL text/plain,
BODYSTRUCTURE and ENVELOPE over isn't really that bad at all. It'll
probably *still* be smaller in total size as your current summary
retrieval (because you don't support TLS compression a.t.m.).

And if the IMAP server has COMPRESS, try to support it (but don't call
if it you detected TLS compression already. Then COMPRESS makes no
sense). I once tried to hack deflate/inflate support into Camel's stream
infrastructure ... (it's not hard, I just never finished it)

If you do all this in Tinymail & Modest, you're on the right track.


Next thing that you want is CONVERT ;-), to convert the huge photograph
to a version that is scaled to the maximum resolution of your device, at
the IMAP server, and retrieve the downscaled small photograph instead.

Or even fetch thumbnails to build up your user-interface ten times more
nicely than any existing mobile E-mail client on the market.

IMAP can do all that. (but sure, if people want to misunderstand IMAP,
then that's their own problem)

Going back to do some RDF, SPARQL and Tracker development now ;). We
need to be ready for when you guys need us (you will, you'll see).


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