IMAP annotation for groupware folder descriptions

Tue Oct 30 10:57:48 CET 2007

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_filename=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 <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~