Hi,
Is anybody working on support for shared folders?
If not I volunteer to try and implement them. It doesn't seem too hard, just a lot of work. Especially a number of changes in the IlohaMail IMAP library.
Robin
PS. IlohaMail development seems to be dead, no CVS commits for over 2 years. Does anybody have more info about that? _______________________________________________ List info: http://lists.roundcube.net/dev/
On 9/24/07, Robin Elfrink elfrink@introweb.nl wrote:
Hi,
Is anybody working on support for shared folders?
Not that I know off. Are shared folders part of the standard and always supported? Just curious how it would work etc..
If not I volunteer to try and implement them. It doesn't seem too hard, just a lot of work. Especially a number of changes in the IlohaMail IMAP library.
Sounds good! :)
PS. IlohaMail development seems to be dead, no CVS commits for over 2 years. Does anybody have more info about that?
No, I really think it is dead.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
Not that I know off. Are shared folders part of the standard and always supported? Just curious how it would work etc..
The base IMAP specification allows for shared folders, and the IMAP4 Namespace1 capability enables clients to automatically discover private, shared and public folder-namespaces supported by the server.
Bob
List info: http://lists.roundcube.net/dev/
On Mon, 24 Sep 2007, B. Johannessen wrote:
till wrote:
Not that I know off. Are shared folders part of the standard and always supported? Just curious how it would work etc..
The base IMAP specification allows for shared folders, and the IMAP4 Namespace1 capability enables clients to automatically discover private, shared and public folder-namespaces supported by the server.
I'm using courier-imap with these shared folders (it supports two kinds of shared folders, the one that I use - virtual shared folders - fall into this "You need to check the NAMESPACE capability" category). I'm pretty sure that I brought this feature up on this ML before as well. Due to lack of experience in php programming and time constraints I cannot offer to help you implement that stuff, but I'd be glad to give you another test szenario, if you like. I might be useful enough to fix a minor issue or two - just not the whole problem.
Regards, Ben _______________________________________________ List info: http://lists.roundcube.net/dev/
B. Johannessen wrote:
The base IMAP specification allows for shared folders, and the IMAP4 Namespace1 capability enables clients to automatically discover private, shared and public folder-namespaces supported by the server.
This RFC says in example 5.4:
< A server that contains a Personal Namespace, Other Users' Namespace and multiple Shared Namespaces. Note that the hierarchy delimiter used within each namespace can be different. >
C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
("#public/" "/")("#ftp/" "/")("#news." "."))
S: A001 OK NAMESPACE command completed
So we can have an x number of Personal (==private) Namespaces, an y number of Other Users' Namespaces, and a z number of Shared Namespaces.
At this moment RoundCube only supports one private namespace.
That means that we have some decisions to make:
- Do we support >1 Other Users' and Shared Namespaces?
- Do we support Other and Shared if there's no namespace extension on
the server? 3. Or do we REQUIRE the namespace extension? Do any servers still exist that do not do RFC2342? 4. How do we show the different namespaces in the main mailbox list and in the settings display?
One related question, maybe someone has the answer, before I have to look through all the RFC's:
- If private namespace is called 'INBOX', is that always used as the
INBOX folder, or do setups exist that use 'INBOX{delimiter}INBOX' ?
Robin _______________________________________________ List info: http://lists.roundcube.net/dev/
Robin Elfrink wrote:
- Do we support Other and Shared if there's no namespace extension on
the server? 3. Or do we REQUIRE the namespace extension?
There's no technical reason to require NAMESPACE. Namespaces are server-wide, and can be configured along with other server properties in the configuration file.
Ignoring NAMESPACE and configuring this in the configuration file has other advantages as well:
You get to limit what namespaces are available in RC.
You get to give the namespaces "human" names. Depending on how the
user interface will allow navigation of shared folders, this will be a huge advantage. Examples of namespaces are "#shared", "~" and "news"; not really strings that belong in a user interface. The configuration could allow these to be named, for example, "Public Folders", "Shared Folders" and "News Groups".
- Do any servers still exist that do not do RFC2342?
Probably, but they probably do not support any sort of shared folders.
- If private namespace is called 'INBOX', is that always used as the
INBOX folder, or do setups exist that use 'INBOX{delimiter}INBOX'?
The literal string "INBOX" is defined by the IMAP specification to always refer to the authenticated users inbox. So a folder named INBOX{delimiter}INBOX would be a sub-folder of INBOX confusingly named INBOX.
Bob
List info: http://lists.roundcube.net/dev/
-
B. Johannessen -
Benjamin Podszun -
Robin Elfrink -
till