[Kolab-devel] Declaring a new folder type for Horde preferences

Joon Radley joon at radleys.co.za
Thu Nov 1 05:42:09 CET 2007

Hi Gunnar,

> 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
on principle.

> 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
this hack. 

Best Regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za
Web: www.toltec.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:
> http://permalink.gmane.org/gmane.mail.imap.general/1781
> ...
> (6) Much-discussed ideas that I don't see going anywhere (sorry...) 
> but category (4) if they make it to publication:
>                 annotations
>                 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:
> https://datatracker.ietf.org/idtracker/?search_button=SEARCH&search_fi
> l
> ename=draft-daboo-imap-annotatemore-11.txt&sub_state_id=6
> 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 
> users.
> 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.
> Comments?
> Cheers,
> Gunnar
> > 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
> folder?
> >    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
> configure
> > 	   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
> can
> > 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
> problem
> > 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
> _could_
> > sometimes be created for a folder?
> >
> > Bernhard
> >
> > --
> > Managing Director - Owner: www.intevation.net       (Free Software
> Company)
> > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-
> Konsortium.com.
> > Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 
> > Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver
> Wagner
> > _______________________________________________
> > 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
> https://kolab.org/mailman/listinfo/kolab-format

More information about the format mailing list