Two changes pushed to master

Bron Gondwana brong at
Sat May 14 09:23:34 EDT 2016

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 | INBOX | INBOX (noinferiors) | INBOX | INBOX.INBOX | <invalid> | Alt Folders.INBOX (noinferiors) | INBOX.INBOX.sub | <invalid> | INBOX.sub | INBOX.inbox | <invalid> | Alt Folders.inbox | INBOX.inbox.sub | <invalid> | Alt Folders.inbox.sub Folders | INBOX.Alt Folders | Alt Folders | Alt Folders.Alt Folders 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
  brong at

More information about the Cyrus-devel mailing list