[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN

[Bron Gondwana]

On Tue, Nov 15, 2011 at 10:10:32PM -0800, Mark Crispin wrote:

> On Wed, 16 Nov 2011, Bron Gondwana wrote:

> >The other problems with strict ascendency is that it requires a global lock

> >for the duration of any append, over whatever scope you require the

> >ascendency in.  As you expand out from a single mailbox to the scope of an

> >entire user, you expand the scope of that global lock.

> 

> Not necessarily. If the GUID is expanded to a uint64 then there's no

> reason why the GUID assignment can't be simply:

> 	<acquire mutex>

> 	guid = ++lastguid;

> 	<release mutex>

> You don't care if the GUID space is holey; and with a uint64 you don't

> even care if you end up losing some.


No, it's not that easy.  You need every view before to not include it,
and every view afterwards to include it.


> There are even some systems where ++ is atomic (yes, even if multicore)

> and you don't need the mutex.


That's cheap - making sure you never return these out of order is not.


> The real issue is MULTIAPPEND and its interaction with UIDPLUS.

> Fortunately, you don't have to assign UIDs as messages are uploaded; you

> can defer that until the uploads are completed. Since you now know how

> many messages you are adding, you can claim an entire range of GUIDs via

> 	<acquire guid mutex>

> 	guid = lastguid += nappends;

> 	<release guid mutex>

> Then assign the already-claimed GUIDs at leisure while checking in the

> append.


Only by blocking all reads while this is happening.


> Of course, the appended mailbox needs to be mutexed over all of this, but

> that's less overall concern than the global mutex.


The appended ID scope, if we're using keyword/flags instead of folders, yes.


> >Which no longer have the strict ascendency property, rendering it somewhat

> >worthless.

> 

> The purpose of strict ascendency is for synchronization. Because these are

> multiple views on a single object, you don't need that at the level of a

> view.


This is valuable purely for a client that does a full synchronisation.  For
something which uses MIDs (which only have value within a held TCP connection)


> A view should compromise either on ascendency or on prohibition of insert.

> I would do the compromise on prohibition of insert, which already happens

> if you have a view that focuses on a keywords.


Someone else can insert something which matches your view - unless you have
a non-updating view.


> >Not requiring multiple parallel connections to be informed of changes.

> 

> Why on earth would any well written client require multiple parallel

> connections? Never mind why poorly-written clients need it.


How many clients make multiple parallel connections out there?  Most of
them.  For fucks sake - it's like you're trying to be obtuse.  They
have multiple connections so they can keep IDLE on a folder or two while
they update the STATUS counts on other folders, amongst other things.

And a separate connection to send email, and a separate connection to
get a contacts list, and ...


> >And of course the low handing fruit: UTF-8 throughout, a more regular

> >syntax which simplifies parsing and has space for extentions later so

> >that every command doesn't have its own unique, slightly different

> >parser.

> 

> Which will work great until someone wants to do something that doesn't fit

> within the regular syntax (and/or wants to "improve" the syntax). Enter

> the flames that your insistance upon syntax regularity is an evil plot to

> hinder progress, cause loss of market window, and deny little girls their

> very own pony.

> 

> You will discover that phenomenum soon enough. Oh, and don't believe that

> you can enforce protocol integrity. You'll learn what "being microsofted"

> and "embrace, extend, destroy" means.


Oh, it's bound to happen.  That's when the next young buck comes along and
comes up with something "better".

Bron.