[Kolab-devel] Declaring a new folder type for Horde preferences
joon at radleys.co.za
Thu Nov 1 05:42:09 CET 2007
> I read a lot of old mails on this list but I couldn't find the basis
> for the idea of using the METADATA extension.
At creation of a folder in Outlook the type of the folder must be known.
Marking the expected content type of objects in a folder is a very good idea
> But as Joon mentioned in one of the recent mails there seemed to be
> possible alternatives. He mentioned hidden messages. Can somebody
> elaborate on this?
It is a "special" message inside the mailbox. This is the most horrible hack
in a multi client environment. Annotation offered the cleanest solution to
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za
> -----Original Message-----
> From: kolab-format-bounces at kolab.org [mailto:kolab-format-
> bounces at kolab.org] On Behalf Of Gunnar Wrobel
> Sent: 30 October 2007 11:58 AM
> To: kolab-format at kolab.org
> Subject: Re: IMAP annotation for groupware folder descriptions
> Bernhard Reiter <bernhard at intevation.de> writes:
> > Hi Joon,
> > On Tuesday 25 September 2007 07:34, Joon Radley wrote:
> >> Should we just move completely to the hidden message solution and
> avoid all
> >> the issue with the annotation database and the fact that it seems
> that the
> >> annotation extension will not be widely adopted by other IMAP4
> servers and
> >> only partially by Cyrus?
> > I think so far that the annotation solution is good and we should
> keep it.
> This morning I read this mail from Mark Crispin:
> (6) Much-discussed ideas that I don't see going anywhere (sorry...)
> but category (4) if they make it to publication:
> LIST extensions
> A while ago I wrote to this list that I think the METADATA (or
> "annotations") extension is no dead end. But now I reconsidered and I
> would like to suggest to broaden the Kolab Format definition to make
> it work with a wider set of possible environments.
> Let me first recap the current situation:
> As we know the METADATA draft hasn't moved in quite a while:
> Assuming that it makes it into a RFC we'd need to get it into
> c-client. Since Mark Crispin is against the proposal this will be
> hard. I know that he favors a setting where this could be added as a
> special plugin.
> The problem with the plugin approach is that this might make it even
> more difficult to get this upstream into PHP which is the ultimate
> reason why we need this in c-client at all.
> I don't see any useful shortcuts to this procedure. The only thing
> that I think that would be really, really useful is if somebody would
> code a dovecot plugin for the METADATA extension so that we get a
> second server supporting this. This might help to build support for
> the extension.
> Anyhow to me this looks like we are going to be stuck with the current
> situation where we use a patched cyrus-imap, a patched c-client and a
> patched PHP for at least another two years, probably more.
> Is this a problem?
> No, not really if you think in terms of Kolab2/OpenPKG. Since OpenPKG
> is it's own little world we can patch as much as we like on this
> system and will always be fine.
> But in general I believe it makes sense to use solutions that don't
> lock people down. And I'd like to see the Kolab format being used a
> little bit more frequently than it is being used at the moment. This
> should have a beneficial long term effect because we'll have more
> people being interest in getting the format supported.
> What I'd like to suggest:
> We should define a second, optional possibility for setting the folder
> type. This approach should use standard IMAP capabilities. This is
> something that a client MAY implement.
> I read a lot of old mails on this list but I couldn't find the basis
> for the idea of using the METADATA extension. But as Joon mentioned in
> one of the recent mails there seemed to be possible alternatives. He
> mentioned hidden messages. Can somebody elaborate on this?
> I'm definitely not suggesting to drop the METADATA extension support.
> I do believe it is the correct solution if we use special folder types
> as we are doing it right now.
> But I'm against blocking ourselves in the direction of standard IMAP
> clients if it is unlikely that we see wider METADATA support in the
> next few years.
> There is one concrete idea I'm connecting with this suggestion:
> Google apparently started offering IMAP access to Gmail. If a Kontact
> client is capable of supporting Kolab style data storage based on any
> standard IMAP server this would open up some nice possibilities for
> I believe this might attract quite a lot of people that want to use a
> Groupware on a small scale and thus provide a significant boost to
> Kolab style data storage. It would allow users to use a groupware
> without any additional setup needed if Kontact (and/or the outlook
> connectors) would support this scheme. For Horde you'd only need to
> install this on your web server.
> > When looking at the discussion I believe that there are two issues:
> > a.1) Should the Horde capability be kept to add a description for a
> > a.2) If so, how? With annotations there would be the question:
> Which one?
> > It would only be one annotation, so this is no problem to
> > Cyrus to allow it.
> > I think a.1) should first be decided, the discussion was started on
> > kolab-devel.
> > I still maintain that it is not necessary and should be disabled in
> the Kolab
> > Horde driver for consistency reasons with other clients and lack of
> > additional value.
> > b) How many variety do we need with annotation names for Toltec?
> > Joon, I did so far not realize that you need to be free to change
> > the annotation-name itself. I believe that we can develop a method
> > that
> > be implemented in Cyrus that allows for subtypes to be choosen.
> > It just would be a bit more complicated in the implementation, as it
> > would need to take a limit into account. It should be no
> > to always keep patches around that losen this limit for now.
> > So there is no reason to chance the client implementations.
> > Joon: Can you give us an example of a list of annotations that
> > sometimes be created for a folder?
> > Bernhard
> > --
> > Managing Director - Owner: www.intevation.net (Free Software
> > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-
> > Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> > Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver
> > _______________________________________________
> > Kolab-format mailing list
> > Kolab-format at kolab.org
> > https://kolab.org/mailman/listinfo/kolab-format
> ______ http://kdab.com _______________ http://kolab-konsortium.com _
> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
> E-mail : p at rdus.de Dr. Gunnar Wrobel
> Tel. : +49 40 432 72335 Bundesstrasse 29
> Fax : +49 40 432 70855 D-20146 Hamburg
> >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> Kolab-format mailing list
> Kolab-format at kolab.org
More information about the format