I've just pushed two changes to master along with some Cassandane tests.  For 
the first time in a while, EVERY Cassandane test should be passing.

One of the commits fixed the JMAP code to match the new scheduling changes, so 
those tests pass again.  It now handles the Schedule-Address header, or reading 
from the existing spool record - and sets the spool records correctly too.

The other is a massive rewrite of mboxlist_findall to return a 'struct 
findall_data' - which includes the extname, the mbentry, the mbname, and the 
"category".  I think I've shown Nicola some of this, and I'll be showing her 
some more of it as we update the FastMail docs to match.  In summary, I've 
moved every folder that can't exist in Alt Namespace into a magic toplevel name 
which defaults to 'Alt Folders'.

internal | normal | old altnamespace | new altnamespace
user.foo | INBOX | INBOX (noinferiors) | INBOX
user.foo.INBOX | INBOX.INBOX | <invalid> | Alt Folders.INBOX (noinferiors)
user.foo.INBOX.sub | INBOX.INBOX.sub | <invalid> | INBOX.sub
user.foo.inbox | INBOX.inbox | <invalid> | Alt Folders.inbox
user.foo.inbox.sub | INBOX.inbox.sub | <invalid> | Alt Folders.inbox.sub
user.foo.Alt Folders | INBOX.Alt Folders | Alt Folders | Alt Folders.Alt Folders
user.foo.Other Users | INBOX.Other Users | <invalid> | Alt Folders.Other Users

And you can dot-stuff as many "Alt Folders" as you like :)

So everything is representable in a reversible way inside Alt Folders.  You 
still get the "No Inferiors" appearing on a single folder, but it's not the top 
level INBOX.  For people living entirely in Alt Namespace, it will all make 
perfect sense.  For people crossing between the two representations, sure 
things get weird - but it's explainable weird.

This isn't going to FastMail production straight away - I'm reverting it again 
on our branch until we have a launch plan - but there's the new code!

One warning for users: it gets called with the 'data' parameter NULL on every 
change between namespaces, so make sure your callees check for NULL.  Most of 
them just if (!data) return 0; at the top, but the smarter ones can do thing 
like reset their internal childinfo state, because you can never have 
parent/child relationships across the namespace boundary :)  That's the main 
point of doing it, because otherwise INBOX would look like it had children in 
Alt Namespace even if it didn't!


  Bron Gondwana

Reply via email to