Sorry for the unclarity... applying a9 then making smaller patches to fix it
will be easier than building patchset a10.
There are a couple of loosely-defined namespace keywords, #users was one,
#shared seemed to be another. But then there was also a suggestion for
~username. The Namespace RFC is really fascinating because it is written using
the dissection method. They give examples of how they want the protocol to
look on the wire, then explain how and why it looks that way.
I'm tempted to suggest that the namespaces should be configurable... but
there's actually a very important implicit "MUST" in the RFC: that is, there
are three namespaces: personal, other users, shared.
So there's three things to configure: personal prefix, others prefix, shared
prefix. At the very least, these should be #define's in the source, if not
fully configurable. With respect to shared mailboxes, it's also very likely
that someone will have access to multiple shared boxes and to multiple shared
namespaces. By my reading of the RFC, you can have multiple separate
namespaces in each of the three categories... I have absolutely no idea how
that plays out.
BTW, did you notice that because the Namespace RFC also provides a mechanism
for namespace discovery, it can be used to eliminate the stupid mailbox
separator config item, regardless of whether the implementation supports
shared mailboxes or not? Anyhow...
Aaron
Ilja Booij <ilja@ic-s.nl> said:
> Hi,
> Aaron Stone wrote:
>
> >I skimmed the RFC's for ACL and NAMESPACE, and it looks like you're on
> >exactlythe right track for implementing shared folders The Right Way (TM).
> >
> >
> Indeed. When I started reading those RFC's the same thought occured to
> me. If only I had read them earlier..
>
> I still have to think of an elegant way to implement the namespaces
> though. Probably a change to db_findmailbox()
> should do the trick, by also allowing it to find mailboxes with names like:
> #users/joeuser/INBOX (which would translate to finding a mailbox in the
> database with name "INBOX", owned
> by user "joeuser". I have to be careful not to break POP and/or the
> delivery chain though.
>
> >Incidentally, it looks like some of the changes may impact the LMTP/Sieve
> >patches. I know you pointed out a couple of bugs to me, but it would be
> >infinitely easier to correct those with little patches against current CVS
> >than by rebuilding the whole patch set or trying to make smaller patches
> >against a hypothetical kinda-close-to-CVS target.
> >
> >
> I'm not totally clear on what you're saying here (must be the lack of
> caffeine in my bloodstream ;). Don't worry,
> I'm working on that as I'm typing this).
>
> Do you mean:
> apply lmtpd-sieve-patch-a9
> apply small fix patches
> ready
>
> instead of
> create big a10 patch
> apply big a10 patch
> ready
>
> ?
>
> Bye,
> Ilja
> --
>
> IC&S
> Stadhouderslaan 57
> 3583 JD Utrecht
>
> PGP-key:
> http://www.ic-s.nl/keys/ilja.txt
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--