I attached a screenshot. The piece of code that deals with local stuff is in place. What for example remains to be done is copypasting the BINART receiving IMAP code, and putting the receive strategy as default for IMAP. You can see the parts are put there the way they'll be received. I replaced that 3_2 with an JPEG image. When you receive BINARY, you get the exact content as is (not encoded anymore). So that's what you'll have on your disk too (if you'd have a message with an IMAGE/JPEG). Normally only 3_1.1 and 3_2 are requested, as those are the only ones that are visible. If an HTML component is available, 3_1.2 is requested too. Those translate to: tag1 FETCH 3 BINARY[1.1] > 3_1.1 tag2 FETCH 3 BINARY[1.2] > 3_1.2 tag3 FETCH 3 BINARY[2] > 3_2 When 3_2 is requested, I could CONVERT this part (with a modern IMAP server). You could make TnyMsgReceiveStrategy implementations that influence the behaviour of CONVERT, if available, to match the device's capabilities. We could make this implementable by the application developer. We could offer a CONVERT-manipulating API and give the app. dev. easy default recipes to get this actually working and easy to use. I might for Tinymail 2.0 rename TnyMsgReceiveStrategy to for example TnyMimePartReceiver (I don't think Modest is using these types anyway at this moment): the very idea behind receiving entire message ain't going to work the way I envisioned it to work (I had things like CONVERT in mind when I decided it to be a strategy pattern). This code will be disconnected from the interactive IMAP session done by Camel (for controlling the IMAP account): It will typically happen in a new socket. This could even be a Python script that runs, as the only thing the contract will require is returning the bodystructure's string (or maybe returning a parsed bodystructure, I'm not sure yet) and implementing getting the parts and storing them in the cache location. I'm of course planning to provide a clean default implementation that reuses Camel's code for this (at least initially) with of course the easy to use helper CONVERT-API to tweak and utilise CONVERT, if available. That's the concept. From concept to reality, especially given that I will be doing another unrelated project full time, will definitely take its time. Once it's done, though, it'll be a great feature for mobile. Feel free to join this effort. We could for example start a branch and cooperate on ideas and coding. -- 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
Attachment:
test.jpg
Description: JPEG image
