[haiku-development] Re: [GSoC proposal] IMAP FS - A few queries
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 22 Apr 2011 05:02:43 +0200
On Thu, 21 Apr 2011 19:15:59 +0530 Anshul Singhle <xashck@xxxxxxxxx> wrote:
> > On Wed, 20 Apr 2011 17:50:55 +0530 Anshul Singhle <xashck@xxxxxxxxx>
> > wrote:
> > "6. Offline Operation : If the FS is mounted and the user is offline,
> the
> > operations done by the user will be stored in queue ( Implemented as a
> file
> > per mailbox) . When the user comes online again, these will be forwarded
> to
> > the mail_daemon."
> >
> > It will have to be sophisticated than that. A main feature of IMAP is
> that
> > an account can be used by different clients (even simultaneously).
> Instead
> > of queuing differences I'd recommend using a snapshot of the last
> > synchronization state and diffing both the local and that server state
> > against it.
> >
> Yes, that does make more sense . A major challenge would be handling
> clashes, consider the following case -
> The last synchronized state is S1, since then you did some operations on
> IMAPFS and went to S2, before you go online, the server state changed from
> S1 to S3. So when we synchronize again, we convert S1 to S3 on the local
> FS.
> Then we merge changes from S2.
It could be done that way, or one could directly compare the diffs S1->S2 and
S1->S3. That's an implementation detail, though. I'd think a bit more about
this and/or see how it works out in practice.
> The major challenge is resolving clashing.
Assuming that mail content cannot be changed, I don't think conflicts will be
all that complicated to solve. You can essentially only add, remove, and move
mails and change their flags. It's just a matter of using conservative rules
and prioritize certain (e.g. local) changes. E.g. if one side removes and the
other moves or otherwise changes the mail, ignore the remove; in case of two
different moves let one move win; etc.
> However, this operation may be very expensive. Is it better if we store
> only
> the diff's?
The diffs are needed for the merge operation, but I think they aren't really
practical for the file system operation. E.g. locally you must present S2 to
the user, so storing S1 and a diff S1->S2 is probably tedious. Storing S2 and a
reverse diff S2->S1 would be possible, but maintaining the reverse diff could
be annoying. Moreover when synchronizing, one would have to reconstruct S1 to
be able to diff against S3. It might be easier to just archive S1 after
synchronizing -- particularly when one maintains index files anyway and would
just have to copy/zip them. But again, that's an implementation detail. I'd
recommend to think some more about it and choose something that is relatively
easy to implement. If necessary it can be improved/replaced later.
> To resolve clashes and stuff we could use algorithms used by
> Version Control systems like Git maybe?
Sounds way to complicated.
> This is going a little off-beat
> and
> maybe in the first iteration I could implement this trivially and adding
> performance enhancing stuff later.
+1
> > "7. mail_daemon : Initially, IMAP FS will just use mail-daemon to send
> and
> > recieve mail. However, in the future it will be better integrated with
> > mail-daemon so that mail-daemon is able to use IMAP FS as storage. This
> will
> > make IMAP FS more mainstream as well as transparent so that users can
> use
> > the familiar mail-daemon without being aware of IMAP FS and also enable
> > mail-daemon to leverage the capabilities offered by IMAP-FS."
> >
> > I'm utterly clueless what you have in mind. Please describe the current
> > mail daemon programming and user interfaces and how you intend to
> use/change
> > them.
> >
> Let me clarify, I will use the mail_daemon externally initially. There is
> an
> IMAP lib interface that can used to retrieve mails using the mail-daemon.
> Note that this will not change the way mail-daemon works. After the IMAP -
> FS operations have been tested, the mail-daemon code will be modified so
> that it uses IMAP FS to store mails. Specifically the implementation of
> IMAPStorage in IMAP Lib of mail-daemon will be changed so that instead of
> storing each mail as file it simply stores the mail in the IMAPFS cache. A
> more detailed note on this later.
I'm not really familiar with the mail subsystem architecture -- so please
correct me, if I'm wrong here -- but from the directory structure I would have
said mail daemon itself is protocol agnostic and just uses protocol add-ons.
Among those is an add-on for IMAP which in turn uses the "imap_lib". So I
really don't understand how you intend to let IMAP FS use the mail daemon which
itself doesn't know anything about IMAP. I can see -- and I thought that was
what Clemens suggested -- that IMAP FS would directly (re)use "imap_lib".
CU, Ingo
Other related posts: