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. -- Bron Gondwana br...@fastmail.fm
