Re: Two changes pushed to master
Wow, that was trivial in the end. Thanks :)
On Wed, Jun 22, 2016, at 11:16 AM, Bron Gondwana via Cyrus-devel wrote:
> Fixed
>
> On Wed, Jun 22, 2016, at 11:07, Bron Gondwana via Cyrus-devel wrote:
> > Oh yeah :p
> >
> > [config]
> > reverseacls = yes
> >
> > I'll fix the test to include that. The shared addressbooks only work with
> > reverseacls turned on.
> >
> > On Wed, Jun 22, 2016, at 10:43, ellie timoney via Cyrus-devel wrote:
> > > I'm still getting grief from the two Caldav sharing tests:
> > >
> > > sharing_samedomain: https://paste.fedoraproject.org/382871/66554226/
> > > sharing_crossdomain: https://paste.fedoraproject.org/382872/14665543/
> > >
> > > I've had a good deep dig into the error report, and it really looks like
> > > Cyrus just isn't returning the shared calendars.
> > >
> > > Looking specifically at sharing_samedomain for now, here's the part of
> > > the test where things start going awry:
> > >
> > > > $talk2->NewAddressBook("Shared", name => "Shared Address Book");
> > > > $admintalk->setacl("user.user2.#addressbooks.Shared\@example.com",
> > > > "user1\@example.com", 'lrsn');
> > > >
> > > > my $Addressbooks = $talk1->GetAddressBooks();
> > > >
> > > > $self->assert_deep_equals([
> > > > {
> > > > 'name' => 'personal',
> > > > 'isReadOnly' => 0,
> > > > 'path' => 'Default',
> > > > 'href' =>
> > > > '/dav/addressbooks/user/us...@example.com/Default/'
> > > > },
> > > > {
> > > > 'path' => '/dav/addressbooks//us...@example.com/Shared',
> > > > 'href' =>
> > > > '/dav/addressbooks//us...@example.com/Shared/',
> > > > 'name' => 'Shared Address Book',
> > > > 'isReadOnly' => 1,
> > > > }
> > > > ], $Addressbooks);
> > >
> > > => create a new addressbook "Shared" on user2
> > > => give user1 "lsrn" rights to it
> > > => look up user1's address books
> > > => expect to find user1's "Default" addressbook, and user2's "Shared"
> > > addressbook
> > >
> > > The output from these actions starts at line 201 (which fpaste doesn't
> > > let me link directly to, doh).
> > >
> > > You can see it creating the addressbook (201 Completed), setting the acl
> > > (OK Completed), and then it asks for user1's addressbooks:
> > >
> > > > PROPFIND
> > > > http://127.0.0.1:9100/dav/addressbooks/user/us...@example.com/ HTTP/1.1
> > > > > > > xmlns:C='urn:ietf:params:xml:ns:carddav'>
> > > >
> > > > HTTP/1.1 207 Multi-Status
> > >
> > > And the response XML (with the long lists of privileges snipped out, for
> > > readability):
> > >
> > > >
> > > > > > > xmlns:XFA68="urn:ietf:params:xml:ns:caldav"
> > > > xmlns:CY="http://cyrusimap.org/ns/";>
> > > >
> > > > /dav/addressbooks/user/us...@example.com/
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [snip]
> > > >
> > > >
> > > > HTTP/1.1 200 OK
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > HTTP/1.1 404 Not Found
> > > >
> > > >
> > > >
> > > > /dav/addressbooks/user/us...@example.com/Default/
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [snip]
> > > >
> > > >
> > > > HTTP/1.1 200 OK
> > > >
> > > >
> > > >
> > >
> > > There are two responses in this:
> > >
> > > * one for user1's top level (the "addressbook-home-set"? I don't think
> > > NetCardDAVTalk includes this in the returned list of addressbooks)
> > > * one for user1's "Default" calendar
> > >
> > > But there's no response in the XML containing the expected "Shared"
> > > addressbook, and so we get the test failure:
> > >
> > > > Structures begin differing at:
> > > > $a->[1] = 'HASH(0x455c428)'
> > > > $b->[1] = Does not exist
> > > > at Cassandane/Cyrus/Carddav.pm line 328.
> > >
> > > Index 0 is OK - it contains user1's Default calendar. But index 1,
> > > which we expect to contain user2's Shared calendar, doesn't exist.
> > >
> > > This doesn't seem to be a perl module problem -- it's not that the perl
> > > module is mishandling the response, it's that Cyrus is not providing the
> > > expected response.
> > >
> > > On a hunch, I tried running Cassandane across fm/future, thinking maybe
> > > there was a relevant Cyrus commit that hadn't been sent upstream yet...
> > > but it fails in the same way.
> > >
> > > Any ideas?
> > >
> > > Anyone else finding these two tests failing?
> > >
> > > On Mon, May 16, 2016, at 11:37 AM, ellie timoney via Cyrus-devel wrote:
> > > > On Mon, May 16, 2016, at 11:04 AM, Bron Gondwana via Cyrus-devel wrote:
> > > > > Are you running the latest version of all the perl modules? I
> > > > > suspect I
> > > > > have
> > > > > pushed more recent
Re: Two changes pushed to master
Fixed
On Wed, Jun 22, 2016, at 11:07, Bron Gondwana via Cyrus-devel wrote:
> Oh yeah :p
>
> [config]
> reverseacls = yes
>
> I'll fix the test to include that. The shared addressbooks only work with
> reverseacls turned on.
>
> On Wed, Jun 22, 2016, at 10:43, ellie timoney via Cyrus-devel wrote:
> > I'm still getting grief from the two Caldav sharing tests:
> >
> > sharing_samedomain: https://paste.fedoraproject.org/382871/66554226/
> > sharing_crossdomain: https://paste.fedoraproject.org/382872/14665543/
> >
> > I've had a good deep dig into the error report, and it really looks like
> > Cyrus just isn't returning the shared calendars.
> >
> > Looking specifically at sharing_samedomain for now, here's the part of
> > the test where things start going awry:
> >
> > > $talk2->NewAddressBook("Shared", name => "Shared Address Book");
> > > $admintalk->setacl("user.user2.#addressbooks.Shared\@example.com",
> > > "user1\@example.com", 'lrsn');
> > >
> > > my $Addressbooks = $talk1->GetAddressBooks();
> > >
> > > $self->assert_deep_equals([
> > > {
> > > 'name' => 'personal',
> > > 'isReadOnly' => 0,
> > > 'path' => 'Default',
> > > 'href' => '/dav/addressbooks/user/us...@example.com/Default/'
> > > },
> > > {
> > > 'path' => '/dav/addressbooks//us...@example.com/Shared',
> > > 'href' => '/dav/addressbooks//us...@example.com/Shared/',
> > > 'name' => 'Shared Address Book',
> > > 'isReadOnly' => 1,
> > > }
> > > ], $Addressbooks);
> >
> > => create a new addressbook "Shared" on user2
> > => give user1 "lsrn" rights to it
> > => look up user1's address books
> > => expect to find user1's "Default" addressbook, and user2's "Shared"
> > addressbook
> >
> > The output from these actions starts at line 201 (which fpaste doesn't
> > let me link directly to, doh).
> >
> > You can see it creating the addressbook (201 Completed), setting the acl
> > (OK Completed), and then it asks for user1's addressbooks:
> >
> > > PROPFIND
> > > http://127.0.0.1:9100/dav/addressbooks/user/us...@example.com/ HTTP/1.1
> > > > > xmlns:C='urn:ietf:params:xml:ns:carddav'>
> > >
> > > HTTP/1.1 207 Multi-Status
> >
> > And the response XML (with the long lists of privileges snipped out, for
> > readability):
> >
> > >
> > > > > xmlns:XFA68="urn:ietf:params:xml:ns:caldav"
> > > xmlns:CY="http://cyrusimap.org/ns/";>
> > >
> > > /dav/addressbooks/user/us...@example.com/
> > >
> > >
> > >
> > >
> > >
> > >
> > > [snip]
> > >
> > >
> > > HTTP/1.1 200 OK
> > >
> > >
> > >
> > >
> > >
> > > HTTP/1.1 404 Not Found
> > >
> > >
> > >
> > > /dav/addressbooks/user/us...@example.com/Default/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [snip]
> > >
> > >
> > > HTTP/1.1 200 OK
> > >
> > >
> > >
> >
> > There are two responses in this:
> >
> > * one for user1's top level (the "addressbook-home-set"? I don't think
> > NetCardDAVTalk includes this in the returned list of addressbooks)
> > * one for user1's "Default" calendar
> >
> > But there's no response in the XML containing the expected "Shared"
> > addressbook, and so we get the test failure:
> >
> > > Structures begin differing at:
> > > $a->[1] = 'HASH(0x455c428)'
> > > $b->[1] = Does not exist
> > > at Cassandane/Cyrus/Carddav.pm line 328.
> >
> > Index 0 is OK - it contains user1's Default calendar. But index 1,
> > which we expect to contain user2's Shared calendar, doesn't exist.
> >
> > This doesn't seem to be a perl module problem -- it's not that the perl
> > module is mishandling the response, it's that Cyrus is not providing the
> > expected response.
> >
> > On a hunch, I tried running Cassandane across fm/future, thinking maybe
> > there was a relevant Cyrus commit that hadn't been sent upstream yet...
> > but it fails in the same way.
> >
> > Any ideas?
> >
> > Anyone else finding these two tests failing?
> >
> > On Mon, May 16, 2016, at 11:37 AM, ellie timoney via Cyrus-devel wrote:
> > > On Mon, May 16, 2016, at 11:04 AM, Bron Gondwana via Cyrus-devel wrote:
> > > > Are you running the latest version of all the perl modules? I suspect I
> > > > have
> > > > pushed more recent versions to CPAN that fix these - there were a bunch
> > > > of
> > > > things that required perl module fiddling.
> > >
> > > I think so, at least the DAV ones and their dependencies:
> > >
> > > => Net::DAVTalk 0.09 (from CPAN)
> > > => Net::CardDAVTalk 0.03 (from CPAN)
> > > => Net::CalDAVTalk 0.05+1 (from github)
> > >
> > > The last updates to these on CPAN were a couple of weeks ago, on 2nd and
> > > 3rd of May. These
Re: Two changes pushed to master
Oh yeah :p
[config]
reverseacls = yes
I'll fix the test to include that. The shared addressbooks only work with
reverseacls turned on.
On Wed, Jun 22, 2016, at 10:43, ellie timoney via Cyrus-devel wrote:
> I'm still getting grief from the two Caldav sharing tests:
>
> sharing_samedomain: https://paste.fedoraproject.org/382871/66554226/
> sharing_crossdomain: https://paste.fedoraproject.org/382872/14665543/
>
> I've had a good deep dig into the error report, and it really looks like
> Cyrus just isn't returning the shared calendars.
>
> Looking specifically at sharing_samedomain for now, here's the part of
> the test where things start going awry:
>
> > $talk2->NewAddressBook("Shared", name => "Shared Address Book");
> > $admintalk->setacl("user.user2.#addressbooks.Shared\@example.com",
> > "user1\@example.com", 'lrsn');
> >
> > my $Addressbooks = $talk1->GetAddressBooks();
> >
> > $self->assert_deep_equals([
> > {
> > 'name' => 'personal',
> > 'isReadOnly' => 0,
> > 'path' => 'Default',
> > 'href' => '/dav/addressbooks/user/us...@example.com/Default/'
> > },
> > {
> > 'path' => '/dav/addressbooks//us...@example.com/Shared',
> > 'href' => '/dav/addressbooks//us...@example.com/Shared/',
> > 'name' => 'Shared Address Book',
> > 'isReadOnly' => 1,
> > }
> > ], $Addressbooks);
>
> => create a new addressbook "Shared" on user2
> => give user1 "lsrn" rights to it
> => look up user1's address books
> => expect to find user1's "Default" addressbook, and user2's "Shared"
> addressbook
>
> The output from these actions starts at line 201 (which fpaste doesn't
> let me link directly to, doh).
>
> You can see it creating the addressbook (201 Completed), setting the acl
> (OK Completed), and then it asks for user1's addressbooks:
>
> > PROPFIND
> > http://127.0.0.1:9100/dav/addressbooks/user/us...@example.com/ HTTP/1.1
> > > xmlns:C='urn:ietf:params:xml:ns:carddav'>
> >
> > HTTP/1.1 207 Multi-Status
>
> And the response XML (with the long lists of privileges snipped out, for
> readability):
>
> >
> > > xmlns:XFA68="urn:ietf:params:xml:ns:caldav"
> > xmlns:CY="http://cyrusimap.org/ns/";>
> >
> > /dav/addressbooks/user/us...@example.com/
> >
> >
> >
> >
> >
> >
> > [snip]
> >
> >
> > HTTP/1.1 200 OK
> >
> >
> >
> >
> >
> > HTTP/1.1 404 Not Found
> >
> >
> >
> > /dav/addressbooks/user/us...@example.com/Default/
> >
> >
> >
> >
> >
> >
> >
> >
> > [snip]
> >
> >
> > HTTP/1.1 200 OK
> >
> >
> >
>
> There are two responses in this:
>
> * one for user1's top level (the "addressbook-home-set"? I don't think
> NetCardDAVTalk includes this in the returned list of addressbooks)
> * one for user1's "Default" calendar
>
> But there's no response in the XML containing the expected "Shared"
> addressbook, and so we get the test failure:
>
> > Structures begin differing at:
> > $a->[1] = 'HASH(0x455c428)'
> > $b->[1] = Does not exist
> > at Cassandane/Cyrus/Carddav.pm line 328.
>
> Index 0 is OK - it contains user1's Default calendar. But index 1,
> which we expect to contain user2's Shared calendar, doesn't exist.
>
> This doesn't seem to be a perl module problem -- it's not that the perl
> module is mishandling the response, it's that Cyrus is not providing the
> expected response.
>
> On a hunch, I tried running Cassandane across fm/future, thinking maybe
> there was a relevant Cyrus commit that hadn't been sent upstream yet...
> but it fails in the same way.
>
> Any ideas?
>
> Anyone else finding these two tests failing?
>
> On Mon, May 16, 2016, at 11:37 AM, ellie timoney via Cyrus-devel wrote:
> > On Mon, May 16, 2016, at 11:04 AM, Bron Gondwana via Cyrus-devel wrote:
> > > Are you running the latest version of all the perl modules? I suspect I
> > > have
> > > pushed more recent versions to CPAN that fix these - there were a bunch
> > > of
> > > things that required perl module fiddling.
> >
> > I think so, at least the DAV ones and their dependencies:
> >
> > => Net::DAVTalk 0.09 (from CPAN)
> > => Net::CardDAVTalk 0.03 (from CPAN)
> > => Net::CalDAVTalk 0.05+1 (from github)
> >
> > The last updates to these on CPAN were a couple of weeks ago, on 2nd and
> > 3rd of May. These are the versions I have.
> >
> > I'm using a version of Net::CalDAVTalk from github because it's one
> > commit ahead of CPAN (fixes missing "_method", which caused most of the
> > Caldav tests to fail with the CPAN version).
--
Bron Gondwana
br...@fastmail.fm
Re: Two changes pushed to master
I'm still getting grief from the two Caldav sharing tests:
sharing_samedomain: https://paste.fedoraproject.org/382871/66554226/
sharing_crossdomain: https://paste.fedoraproject.org/382872/14665543/
I've had a good deep dig into the error report, and it really looks like
Cyrus just isn't returning the shared calendars.
Looking specifically at sharing_samedomain for now, here's the part of
the test where things start going awry:
> $talk2->NewAddressBook("Shared", name => "Shared Address Book");
> $admintalk->setacl("user.user2.#addressbooks.Shared\@example.com",
> "user1\@example.com", 'lrsn');
>
> my $Addressbooks = $talk1->GetAddressBooks();
>
> $self->assert_deep_equals([
> {
> 'name' => 'personal',
> 'isReadOnly' => 0,
> 'path' => 'Default',
> 'href' => '/dav/addressbooks/user/us...@example.com/Default/'
> },
> {
> 'path' => '/dav/addressbooks//us...@example.com/Shared',
> 'href' => '/dav/addressbooks//us...@example.com/Shared/',
> 'name' => 'Shared Address Book',
> 'isReadOnly' => 1,
> }
> ], $Addressbooks);
=> create a new addressbook "Shared" on user2
=> give user1 "lsrn" rights to it
=> look up user1's address books
=> expect to find user1's "Default" addressbook, and user2's "Shared"
addressbook
The output from these actions starts at line 201 (which fpaste doesn't
let me link directly to, doh).
You can see it creating the addressbook (201 Completed), setting the acl
(OK Completed), and then it asks for user1's addressbooks:
> PROPFIND
> http://127.0.0.1:9100/dav/addressbooks/user/us...@example.com/ HTTP/1.1
> xmlns:C='urn:ietf:params:xml:ns:carddav'>
>
> HTTP/1.1 207 Multi-Status
And the response XML (with the long lists of privileges snipped out, for
readability):
>
> xmlns:XFA68="urn:ietf:params:xml:ns:caldav"
> xmlns:CY="http://cyrusimap.org/ns/";>
>
> /dav/addressbooks/user/us...@example.com/
>
>
>
>
>
>
> [snip]
>
>
> HTTP/1.1 200 OK
>
>
>
>
>
> HTTP/1.1 404 Not Found
>
>
>
> /dav/addressbooks/user/us...@example.com/Default/
>
>
>
>
>
>
>
>
> [snip]
>
>
> HTTP/1.1 200 OK
>
>
>
There are two responses in this:
* one for user1's top level (the "addressbook-home-set"? I don't think
NetCardDAVTalk includes this in the returned list of addressbooks)
* one for user1's "Default" calendar
But there's no response in the XML containing the expected "Shared"
addressbook, and so we get the test failure:
> Structures begin differing at:
> $a->[1] = 'HASH(0x455c428)'
> $b->[1] = Does not exist
> at Cassandane/Cyrus/Carddav.pm line 328.
Index 0 is OK - it contains user1's Default calendar. But index 1,
which we expect to contain user2's Shared calendar, doesn't exist.
This doesn't seem to be a perl module problem -- it's not that the perl
module is mishandling the response, it's that Cyrus is not providing the
expected response.
On a hunch, I tried running Cassandane across fm/future, thinking maybe
there was a relevant Cyrus commit that hadn't been sent upstream yet...
but it fails in the same way.
Any ideas?
Anyone else finding these two tests failing?
On Mon, May 16, 2016, at 11:37 AM, ellie timoney via Cyrus-devel wrote:
> On Mon, May 16, 2016, at 11:04 AM, Bron Gondwana via Cyrus-devel wrote:
> > Are you running the latest version of all the perl modules? I suspect I
> > have
> > pushed more recent versions to CPAN that fix these - there were a bunch
> > of
> > things that required perl module fiddling.
>
> I think so, at least the DAV ones and their dependencies:
>
> => Net::DAVTalk 0.09 (from CPAN)
> => Net::CardDAVTalk 0.03 (from CPAN)
> => Net::CalDAVTalk 0.05+1 (from github)
>
> The last updates to these on CPAN were a couple of weeks ago, on 2nd and
> 3rd of May. These are the versions I have.
>
> I'm using a version of Net::CalDAVTalk from github because it's one
> commit ahead of CPAN (fixes missing "_method", which caused most of the
> Caldav tests to fail with the CPAN version).
Re: Two changes pushed to master
On Mon, May 16, 2016, at 11:04 AM, Bron Gondwana via Cyrus-devel wrote: > Are you running the latest version of all the perl modules? I suspect I > have > pushed more recent versions to CPAN that fix these - there were a bunch > of > things that required perl module fiddling. I think so, at least the DAV ones and their dependencies: => Net::DAVTalk 0.09 (from CPAN) => Net::CardDAVTalk 0.03 (from CPAN) => Net::CalDAVTalk 0.05+1 (from github) The last updates to these on CPAN were a couple of weeks ago, on 2nd and 3rd of May. These are the versions I have. I'm using a version of Net::CalDAVTalk from github because it's one commit ahead of CPAN (fixes missing "_method", which caused most of the Caldav tests to fail with the CPAN version).
Re: Two changes pushed to master
On Mon, May 16, 2016, at 10:25, ellie timoney via Cyrus-devel wrote: > > For the first time in a while, EVERY Cassandane test should be passing. > > I'm still (just now) getting failures from Carddav.sharing_samedomain > and Carddav.sharing_crossdomain: > https://paste.fedoraproject.org/366966/63357613/ > > I dug into these a bit on Friday afternoon, and in both cases the return > from GetAddressBooks() didn't include the shared addressbook, so the > assert_deep_equals would fail. I imagine (but haven't verified) that > the same thing is happening now too. Any ideas? Are you running the latest version of all the perl modules? I suspect I have pushed more recent versions to CPAN that fix these - there were a bunch of things that required perl module fiddling. Bron. -- Bron Gondwana br...@fastmail.fm
Re: Two changes pushed to master
> For the first time in a while, EVERY Cassandane test should be passing. I'm still (just now) getting failures from Carddav.sharing_samedomain and Carddav.sharing_crossdomain: https://paste.fedoraproject.org/366966/63357613/ I dug into these a bit on Friday afternoon, and in both cases the return from GetAddressBooks() didn't include the shared addressbook, so the assert_deep_equals would fail. I imagine (but haven't verified) that the same thing is happening now too. Any ideas? On Sat, May 14, 2016, at 11:23 PM, Bron Gondwana via Cyrus-devel wrote: > 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 | | Alt Folders.INBOX > (noinferiors) > user.foo.INBOX.sub | INBOX.INBOX.sub | | INBOX.sub > user.foo.inbox | INBOX.inbox | | Alt Folders.inbox > user.foo.inbox.sub | INBOX.inbox.sub | | Alt Folders.inbox.sub > user.foo.Alt Folders | INBOX.Alt Folders | Alt Folders | Alt Folders.Alt > Folders > user.foo.Other Users | INBOX.Other Users | | 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
Two changes pushed to master
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 | | Alt Folders.INBOX (noinferiors) user.foo.INBOX.sub | INBOX.INBOX.sub | | INBOX.sub user.foo.inbox | INBOX.inbox | | Alt Folders.inbox user.foo.inbox.sub | INBOX.inbox.sub | | Alt Folders.inbox.sub user.foo.Alt Folders | INBOX.Alt Folders | Alt Folders | Alt Folders.Alt Folders user.foo.Other Users | INBOX.Other Users | | 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
