On Tue, Apr 27, 2004 at 09:48:31PM +0300, Timo Sirainen wrote:
On Tue, 2004-04-27 at 15:53, Tom Alsberg wrote:
That's what I mean - when the IMAP COPY command is issued, the From_ line should be copied together with the rest of the actual message.
I don't think I'll want to do the copying exactly,
That's a shame... Any tips, though, on how I could change it in the least ugly-hackish way? (I'd like to see and know in order to understand the internal architecture of dovecot anyway, even if you are soon to implement it with the read and save API into the mainstream code track)
as the way COPY currently works is "read message" and "save message", although maildir has special code for hardlink-copying. I don't think mbox really deserves that..
Well, OK... Not sure why, though - I'd think this would be a small piece of code specific to mbox (if done right), and would warrant a special case.
However, I could change read and save APIs so that the "envelope from" can be read and written. With maildir reading would give NULL, and writing would just ignore it. With mbox it would work right though, and if it's NULL it'd do what it does now.
Sounds like a good idea. I'd also think of trying to base on Return-Path: if it's NULL when writing to an mbox, before dropping to inventing a completely fabricated one, but that's just an added bonus...
Any idea as to when I could expect to have this implemented in dovecot? (I'd love to help with it, given some guidance)
Main question in my mind now about the code: What data is kept in the context of a message, except for the istream pointing to the contents? (As in - where would you insert that "envelope from" field? Would it just be a parameter to the functions, or would it be some field in the data structure representing a message?)
I understood that in the current development dovecot, mbox support doesn't even work anymore... I do hope that'll be fixed when it becomes the current stable branch.
I must say that until now I really like dovecot, being the best IMAP server I've found until now (most suitable to my needs, but also clean and flexible, functioning well...). Hopefully mbox support won't just be dropped at some point, as it is important for me, and I believe for other users as well.
I understood the direction of development right now is into making dovecot as modular as feasible, so maybe even if mbox support won't be in the main dovecot code, it could be an external module (with a clean enough API, I could even write and maintain an mbox module)
Thank you, Timo, and the rest of the dovecot developers, for all the efforts into this neat piece of software :-)
Thanks again, -- Tom
-- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further.