Well, for one, this requires change to Cyrus, which Phil doesn't seem to want to do.
Also, it still doesn't solve the problem of flag changes. -Rob On Tue, 4 Feb 2003, Kendrick Vargas wrote: > I've been sorta following this thread, and I don't claim to know a whole > lot about programming, but I'm wondering why something simple like what > I'm about to suggest wouldn't work... Here goes: > > If a group of servers are gonna be in constant communication, why not just > have each server assign UID's in increments of the number of servers in > the group? For example, if you have 3 servers, and they realize they've > disconnected, each of the servers could number in increments of 3 starting > from different points. > > Assuming the last UID was 502, server 1 would receive messages and number > them as 503, 506, 509, etc... Server 2 would number at 504, 507, 510, etc. > And Server 3 would number at 505, 508, 511, etc. When the servers > re-connect, the file numbers would be unique, the biggest issue you'd run > into would be that the incomming sort order will be a little off, and not > really. If the user sets their MUA to sort on date, it would be even less > of an issue. > > Why wouldn't something like this work? I mean, assuming that there's some > logic involved in the software, the individual servers could figure out > which incremented number they could use as their UID next. > -peace > > On Tue, 4 Feb 2003, Mark Keasling wrote: > > > On Tue, 4 Feb 2003 03:19:12 -0600, Phil Howard <[EMAIL PROTECTED]> wrote... > > > > > On Tue, Feb 04, 2003 at 02:16:36AM -0500, Rob Siemborski wrote: > > > > > > | On Tue, 4 Feb 2003, Phil Howard wrote: > > > | > > > | > Does the RFC say that the IMAP UIDs have to be the file name? > > > | > > > | No, of course not. > > > | > > > | > Do the IMAP UIDs have to be the same between different sessions? > > > | > > > | They cannot change without also chanigng the UIDVALIDITY of the mailbox, > > > | which is an expensive operation for disconnected clients (it forces them > > > | to resync) > > > | > > > | So yes, every time you need to resync, you can increment the uidvalidity, > > > | but your disconnected users are going to hate you for it, and this isn't a > > > | tremendously good solution for the real world (where temporary outages > > > | between distant nodes is the norm). > > > > > > So the message with UID 123 during one session has to still have UID 123 > > > during the next session. That indeed will break the ability to have > > > unique remote syncronization. > > > > Not really, it just makes it much more complex. When the machines > > reconnect, they would need to have a way to determine if the same uid > > was referring to two different messages. If so, appending those messages > > to the end of the folder with new uids and deleteing the old uid would > > re-uniquify the messages. You may want to do that with all of the > > messages that two machines received while they were incommunicado. > > Essentially, the machines would have to remember their UIDNEXT value at > > the time that communication was lost. Once communication was reestablished, > > all of the messages from the old UIDNEXT upto the current UIDNEXT held > > by each machine would need to be moved (append and delete) to the end of > > the folder. The new uids would start from the largest UIDNEXT held by > > either machine. I think something like that would workat least in theory. > > > > The main problem would be if the two machines appeared to users as > > the same machine due to DNS trickery and a user could connect to either > > one but the machines still could not connect to each other. (One leg out > > of the triangle) In that case, the user's client could see the mailbox > > having one message one time and a different message the next even though > > the uid was the same. So if the client connected, fetched enough info to > > make a message cache list and then disconnected. If the next time it > > connected to the other machine to fetch the message, the result would not > > be what was expected. > > > > > What's curious to me is how, with a Maildir format, that IMAP could be > > > implemented to retain that state without either storing some extra data > > > or updating the files in place. I had thought that real unique message > > > IDs were the same as in RFC 822. I didn't read RFC 2060 because I had > > > been talked out of implementing my own IMAP daemon. But I guess I > > > should have read it, anyway, to understand its limitations. Probably > > > better do that soon before I design something else that can't work :-) > > > > > > -- > > > ----------------------------------------------------------------- > > > | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | > > > | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/ | > > > ----------------------------------------------------------------- > > > > > > Regards, > > Mark Keasling <[EMAIL PROTECTED]> > > > > > > -- > Let he who is without clue kiss my ass > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
