On Fri, 2003-02-21 at 17:43, Steve Hole wrote: > On 21 Feb 2003 07:34:59 +0200 Timo Sirainen <[EMAIL PROTECTED]> wrote: > > > I'd like to know how you can make a client efficiently handle sequence > > numbers. If internal message structure contains just the sequence > > number, it has to be updated every time an older message is deleted. > > Since it's just memory it's not too slow, but I can't see how that could > > be better (from client's point of view) than simply using UIDs where you > > don't have to do any updates at all. > > Sigh. Please go back and read the archives of this group. Have a look > at the c-client code. Really, it takes but a moment of thought to figure > out how to use sequence numbers efficiently and how to integrate them > flawlessly with UID. It also shows why they are useful in efficient > client construction.
OK, I looked through c-client and Pine code. It looks just as difficult as I expected. It uses multiple arrays for seq <-> message lookups. It often has to go through the whole array just to find the message (for every message it has to fetch I think?). And of course it has to update the arrays every time messages are expunged. Pine also doesn't seem to do any automatic reconnection to server. I'd think that would get annoying with bad internet connections. If it did do reconnecting, would the current code require resyncing everything after connect (useless bandwidth usage) or could it somehow handle updating it's internal seq. numbers to match against cache other than FETCH 1:* UID, which was supposed to be evil? Well, I guess "SEARCH UID <all cached message uids>" would work too, but that doesn't seem that good idea either. Again, I see it useful only for on-demand loading when message UIDs aren't already known. For everything else using a few hash tables for UIDs would be faster and simpler to implement. Actually, even if client didn't remember sequences, it could still fetch the "next pageful" with one extra SEARCH command: 1 SEARCH UID <uid of last visible message> * SEARCH 120 2 FETCH 121:140 (...) I'll start reading the archives next.
