[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