Hi Stefano, Am Freitag, den 17.11.2006, 19:23 +0100 schrieb Stefano Bagnara:
> Can you elaborate on the "namespaces"? > Is namespace only the first part of the path? Why do we deserve a > special name for it? It's again an IMAP thing. (JavaMail as being close to IMAP, supports it too). http://www.rfc-editor.org/rfc/rfc2342.txt http://java.sun.com/products/javamail/javadocs/javax/mail/Store.html#getSharedNamespaces() It's a bit like windows drives. So there can be more than one root. The client can ask for the namespaces 1. his personal (e.g. "#users.tester") 2. users (e.g. "#users") 3. shared (e.g. "#shared","#news","#system") and gets an idea where to look. The client can visualize this with different icons/structure. To make things more complicated each namespace can have its own hierarchy delimiter e.g. "." or "/". (useful when wiring different implementations together). A namespace has a prefix. But this prefix can be freely chosen. We just should use a commonly used scheme like "#xyz" as a prefix. There may be others. We can start by just supporting one hierarchy delimiter. I personally prefer ".". At the moment and for most operations the namespaces are just a configurable thing to propagate to the (imap) clients. Internally MailboxManager doesn't care which hierarchy delimiter or which prefix you use. (the "flat hierarchy" idea, mailbox names are just strings, we don't care for parents or childs). The only exception is the list command that allows a wildcard that does not match the hierarchy delimiter (-> rfc3501 6.3.8. LIST Command). Important: I consider them as independent from the virtual mounts. So to call the branch "mailbox-namespaces" was probably not well fitting. :-) It may be a common use to mount namespace prefixes to different backends, but it is not a limitation. You can mount to different backends in the same namespace. Conclusion: They are just configured and propagated through MailboxManagerProvider. The implementations don't have to care too much for them. The client does the interpretation. > (I'm not against it, I'm just trying to collect more information :-) ) Great! I just thought about being less verbose this morning, because it takes so much time to elaborate unsolicited big proposals and explanations. So please review and ask such questions, I'll answer willingly! :-) Joachim P.S. the content in the config.xml is a placeholder without a backing implementation. static constants are used at the moment. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
