From bernhard at intevation.de Tue Oct 9 14:44:04 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Oct 2007 14:44:04 +0200 Subject: IMAP annotation for groupware folder descriptions In-Reply-To: <000e01c7ff35$c1f559a0$45e00ce0$@co.za> References: <87fy1kqa9n.fsf@home.pardus.de> <200709250710.01493.martin.konold@erfrakon.de> <000e01c7ff35$c1f559a0$45e00ce0$@co.za> Message-ID: <200710091444.12655.bernhard@intevation.de> 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. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-format/attachments/20071009/800144c4/attachment.bin From wrobel at pardus.de Tue Oct 9 14:53:24 2007 From: wrobel at pardus.de (Gunnar Wrobel) Date: Tue, 09 Oct 2007 14:53:24 +0200 Subject: IMAP annotation for groupware folder descriptions In-Reply-To: <200710091444.12655.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 9 Oct 2007 14:44:04 +0200") References: <87fy1kqa9n.fsf@home.pardus.de> <200709250710.01493.martin.konold@erfrakon.de> <000e01c7ff35$c1f559a0$45e00ce0$@co.za> <200710091444.12655.bernhard@intevation.de> Message-ID: <873awk5u0r.fsf@home.pardus.de> Bernhard Reiter 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. > 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. I disagree since the IMAP METADATA extension specifically defines the "/comment" annotation value for describing a folder. I don't know why the old Kolab module in Horde used a special value for this but I switched to using "/comment" now. This way this is not client specific at all since any IMAP server supporting the METADATA extension will also have to provide the "/comment" annotation. Cheers, Gunnar > > 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 << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bernhard at intevation.de Tue Oct 9 14:55:50 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Oct 2007 14:55:50 +0200 Subject: Fwd: [Kolab-devel] Non-standard IMAP flags in KMail In-Reply-To: <200709250706.03029.martin.konold@erfrakon.de> References: <200709141229.39285.volker@kdab.net> <200709240750.58342.martin.konold@erfrakon.de> <200709250706.03029.martin.konold@erfrakon.de> Message-ID: <200710091455.55725.bernhard@intevation.de> Hi Martin, On Tuesday 25 September 2007 07:05, Martin Konold wrote: > I further investigated this matter. I had hoped you would investigate the extended freebusy lists first? 8) > It looks like you took a totally expired draft (anyone can make up a draft) > as a guideline. Got anything better? We tried to find what is there and how others solve the problem. This is the right approach. When there is just a "totally expired draft", I think it is better to work from there and develop a better one, if we must and can. > I am afraid that this draft did not only expire but it also did not get > enough support fromt he community in order to become a RFC. Got pointers? Was it because of nobody was interested or there were technical things with it or other issues? > Did I overlook some aspect? > > Regards, > -- martin > P.S.: - OL2K7 uses more than a single IMAP Flag What does it use? Could you find out anything specific? > ? ? ? - KONSEC Konnektor for OL would be able to use any available IMAP > Flag just as kmail. Any client would, if they implement the meaning... > ? ? ? - For many purposes a plain boolean flag is not enough. E.g. flags > have colours and replied has a date.... I think we will see how far we get with the easier ones first. We can only put limited efforts in, so we should go for the lower hanging fruits first. > > Am Freitag 14 September 2007 schrieb Volker Krause: > > can you please explain which new commands (if possible verbatim) there > > will be on the IMAP tcp connection? None, I guess. Would we need new commands? > > With which servers did you test? Wouldn't this be more a client then a server issue? 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-format/attachments/20071009/59ef726d/attachment.bin From bernhard at intevation.de Tue Oct 9 15:02:58 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Oct 2007 15:02:58 +0200 Subject: Declaring a new folder type for Horde preferences (was: [Kolab-devel] IMAP annotation for groupware folder descriptions) In-Reply-To: <877ime800w.fsf_-_@home.pardus.de> References: <87fy1kqa9n.fsf@home.pardus.de> <20070919100516.GA1732.thomas@intevation.de> <877ime800w.fsf_-_@home.pardus.de> Message-ID: <200710091503.00009.bernhard@intevation.de> Hi Gunnar, On Wednesday 26 September 2007 07:32, Gunnar Wrobel wrote: > I would like to > use the new folder type named > > ?h-prefs > > From the example given in the Kolab format description I'm not > absolutely certain if this should rather be > > ?kolab.h-prefs > > In any case this folder type will be used to store client preferences, > specifically the Horde preferences. I am quite sceptical about this, until I have read more how the general problem is to be solved in the future, I suggest to discuss this on kolab-devel@ first. (We should also always pick one mailinglist to discuss things, and not crosspost, except for the emails doing the transitions.) > So far Horde used the Kolab LDAP > tree for that but this led to the known problems of including the > Horde LDAP schema in the Kolab server. This would be solvable, I guess. > There were also problems with > the Kolab web admin when using the LDAP based preference system. Solvable also I think. > In addition it is probably not the most appropriate storage location > since the preferences in Horde are bound to be changed rather often > while a user works in Horde. > > As a consequence I would like to store the Horde preferences in a > dedicated "Preferences" folder on the IMAP server. We should look into more concept of where to save client configurations first, as far as I know the Cyrus people also have made some experiments in this regards as can be seen from the webpages. > A draft patch for that would be ready and works fine: > > http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE_CVS/file/tip/framework/HK-GW >-Prefs-Kolab_IMAP.patch > > So my main question is if it okay to declare this new folder type. > > This would of course mean that I'd feel tempted to continue declaring > more folders types such as h-links, h-filter, h-bugs, etc. These all > represent existing Horde applications that simply need storage space > (other than the default SQL storage). But I think I remember there was > some opposition concerning the idea of storing additional data types > on the server :) Unless we are sure that this will solve the general problem, we should not do it in my opinion. If all clients just declare new email and folder-types for their internal data, this seems suboptimal. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-format/attachments/20071009/1b2c9e55/attachment.bin From joon at radleys.co.za Wed Oct 10 07:01:26 2007 From: joon at radleys.co.za (Joon Radley) Date: Wed, 10 Oct 2007 07:01:26 +0200 Subject: IMAP annotation for groupware folder descriptions In-Reply-To: <200710091444.12655.bernhard@intevation.de> References: <87fy1kqa9n.fsf@home.pardus.de> <200709250710.01493.martin.konold@erfrakon.de> <000e01c7ff35$c1f559a0$45e00ce0$@co.za> <200710091444.12655.bernhard@intevation.de> Message-ID: <007001c80afa$9fc1a930$df44fb90$@co.za> Hi Bernhard, > a.1) Should the Horde capability be kept to add a description for a > folder? Yes under another annotation key, but Horde must be able to handle the situation where a folder exist without any description field. > 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. "/vendor/kolab/folder-description"? > b) How many variety do we need with annotation names for Toltec? The confusion is from my side. I need one annotation key, "/vendor/kolab/folder-type", that can handle unlimited variations. The other Kolab key is "/vendor/kolab/incidences-for", this is used by the free busy trigger. 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 Jan-Oliver Wagner From joon at radleys.co.za Wed Oct 10 07:05:31 2007 From: joon at radleys.co.za (Joon Radley) Date: Wed, 10 Oct 2007 07:05:31 +0200 Subject: IMAP annotation for groupware folder descriptions In-Reply-To: <873awk5u0r.fsf@home.pardus.de> References: <87fy1kqa9n.fsf@home.pardus.de> <200709250710.01493.martin.konold@erfrakon.de> <000e01c7ff35$c1f559a0$45e00ce0$@co.za> <200710091444.12655.bernhard@intevation.de> <873awk5u0r.fsf@home.pardus.de> Message-ID: <007101c80afb$317d6670$94783350$@co.za> Hi Gunnar, > I disagree since the IMAP METADATA extension specifically defines the > "/comment" annotation value for describing a folder. I don't know why > the old Kolab module in Horde used a special value for this but I > switched to using "/comment" now. This way this is not client specific > at all since any IMAP server supporting the METADATA extension will > also have to provide the "/comment" annotation. The only reservation I have about this is that it is not specific to Horde and any application that also uses the "/comment" can destroy your values. Now as this is not format specific, this should not be a big issue for Horde. As this is relate to all Kolab clients, maybe define it under "/vendor/kolab/folder-description"? 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 From wrobel at pardus.de Wed Oct 10 08:25:38 2007 From: wrobel at pardus.de (Gunnar Wrobel) Date: Wed, 10 Oct 2007 08:25:38 +0200 Subject: IMAP annotation for groupware folder descriptions In-Reply-To: <007101c80afb$317d6670$94783350$@co.za> (Joon Radley's message of "Wed, 10 Oct 2007 07:05:31 +0200") References: <87fy1kqa9n.fsf@home.pardus.de> <200709250710.01493.martin.konold@erfrakon.de> <000e01c7ff35$c1f559a0$45e00ce0$@co.za> <200710091444.12655.bernhard@intevation.de> <873awk5u0r.fsf@home.pardus.de> <007101c80afb$317d6670$94783350$@co.za> Message-ID: <87ejg332ql.fsf@home.pardus.de> "Joon Radley" writes: > Hi Gunnar, > >> I disagree since the IMAP METADATA extension specifically defines the >> "/comment" annotation value for describing a folder. I don't know why >> the old Kolab module in Horde used a special value for this but I >> switched to using "/comment" now. This way this is not client specific >> at all since any IMAP server supporting the METADATA extension will >> also have to provide the "/comment" annotation. > > The only reservation I have about this is that it is not specific to > Horde and any application that also uses the "/comment" can destroy > your values. Now as this is not format specific, this should not be > a big issue for Horde. Hm, the fact that this is not specific to Horde or another Kolab client is the reason why I would like to use the "/comment" value. Here is the relevant note from the draft: http://ietfreport.isoc.org/idref/draft-daboo-imap-annotatemore/ 3.2.1.2. Mailbox Entries .... /comment Defines a comment or note associated with a mailbox. So if there is any other client using the "/comment" value and it is acting according to the draft, then it makes sense for Horde to actually display this note or comment to the user. The share description used by Horde is nothing different after all. It has no special meaning and is really just a description. It is just there for informational purposes. So even if another client modifies the "/comment" value this should be fine. The only problem I see at the moment is the fact that the Kolab specific set/getannotation PHP patch is broken and does not support UTF8 like it should. But that's a different story. Cheers, Gunnar -- ______ 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 << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From thomas at intevation.de Mon Oct 15 18:38:38 2007 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Mon, 15 Oct 2007 18:38:38 +0200 Subject: Kolab Format specs/Kontact: Question about custom folder types In-Reply-To: <200710151449.56607.bernhard@intevation.de> References: <871wcbja34.fsf@home.pardus.de> <20071005161221.GD27949.thomas@intevation.de> <87zlyophrq.fsf@home.pardus.de> <200710151449.56607.bernhard@intevation.de> Message-ID: <20071015163837.GD23723.thomas@intevation.de> * Bernhard Reiter [20071015 14:49]: > On Friday 12 October 2007 15:46, Gunnar Wrobel wrote: > > > - folders with a folder-type different from "mail" are not mail, so > > > ? SHOULD not be displayed as mail (i.e. hidden). > > > > > > Maybe this should be added to the specs. > > > > I'd be very happy if this could be done. > > I am unsure about the change itself. I don't regard this as a change, only a clarification. > I personally would rather see something that I do not understand > then to overlook that there are possibily additional information. > Also the default for a regular IMAP client would be to display stuff. The same applies for all groupware folders. > > What is required in order to > > get changes into the Kolab format specs? Do I have to open a bug? Are > > people going to vote on it? :) > > You will need to convince the people of kolab-format at . Ok, I just subscribed there, copy of this mail to kolab-format, reply-to set. For people only on kolab-format, the thread started here: http://kolab.org/pipermail/kolab-devel/2007-October/007613.html > We are quite conservative about changing the format because it should > be a solid base for client implementations. And maybe because the format specs are not easy readable in this point, the client implementation of kontact got it wrong. Thomas -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-format/attachments/20071015/0c02d674/attachment.bin From wrobel at pardus.de Tue Oct 16 07:24:15 2007 From: wrobel at pardus.de (Gunnar Wrobel) Date: Tue, 16 Oct 2007 07:24:15 +0200 Subject: [Kolab-devel] Declaring a new folder type for Horde preferences In-Reply-To: <200710151438.01493.bernhard@intevation.de> (Bernhard Reiter's message of "Mon, 15 Oct 2007 14:37:50 +0200") References: <87fy1kqa9n.fsf@home.pardus.de> <200710091503.00009.bernhard@intevation.de> <87odf84e3g.fsf@home.pardus.de> <200710151438.01493.bernhard@intevation.de> Message-ID: <87abqjzl6o.fsf@home.pardus.de> Bernhard Reiter writes: > On Tuesday 09 October 2007 15:22, Gunnar Wrobel wrote: >> > Unless we are sure that this will solve the general problem, >> > we should not do it in my opinion. If all clients just declare new email >> > and folder-types for their internal data, this seems suboptimal. >> >> We don't have to use the IMAP driver on Kolab2/OpenPKG if you don't >> like it. But from the recent discussions it became obvious that the >> current kolab format specification explicitely allows declaring new >> folder types. So why would that be suboptimal? > > Because we would ideally want all clients to understand each other. This is understandable even though "all clients" is a little bit broad and I assume you refer to Kolab-compatible clients. > An unknown folder will be displayed by other clients and look ugly, > beside the danger of it being manipulated by the other clients. Which is a default situation for any non-Kolab-compliant client. Of which there are many. I think this is an indisputable fact: Kolab will always have the problem that a standard IMAP client will display folders to the user that hold unreadable "strange" stuff. I assume that the solution is that the documentation requires the user to use a Kolab-compliant client with a Kolab server. In addition the user is told that using a non-Kolab-compliant client might cause some collateral damage. That is fine and the knowledgeable user of course still has the option to use a plain IMAP client. Back to the Kolab-compatible clients: Your suggestion is to limit the type of folders we use to the set of folder types that are supported by all clients declared Kolab-compliant. This also means to limit the addition of features to the slowest progressing Kolab-compatible client. I assume that we will thus be always slightly behind the Microsoft product. What I'm now asking for is instead to allow clients to use experimental folder types in order to implement new and experimental features. In addition I require that any Kolab-compliant client hides such folders if the client does not recognize the folder type. This would not change the situation for non-Kolab-compliant clients since they don't know about folder types anyhow. So they'll display strange folders in any case. But the situation will also remain unchanged for the Kolab-compliant clients if they hide folder types unknown to them. So there will be no strange stuff visible to the user. In my eyes this gives us free room to experiment and also go beyond Microsoft and Outlook. I look at the Horde client and have no problem to see that potential. And I'm also looking at the Kontact client and have the impression it has the same kind of potential. Why did Kontact implement the plugin framework recently? I don't know enough of Kontacts internals but it looks like this allows you to easily plug in new components. If these are applications that store user data where are they going to store it? The same holds true for Horde. There are applications that do link management or file management. You can install Hermes for time tracking and billing. And there are other apps being coded that provide really interesting possibilities. This just needs to store user data in the Kolab IMAP store. Why should we artificially restrict these possibilities? > Another thought is about data being possibly dublicated and users > confused by this data. I don't really follow. How does the data get duplicated? You mean by a user copying the unknown mails? > > Think about folder descriptions: > You give a folder a description because you are using Horde, which will > save it in its own folder, now you tell our cowording: Its the folder with > this description. But your coworking might be using Kontact and will > not see it. A constructed example. If you use the folder description in Horde you will see that it is not at all a primary identifier for a groupware folder. The likelihood that someone will communicate the folder description without talking about the folder name is negligible. In your example the co-worker would of course also have the possibility to log into Horde to identify the folder. While I understand your desire to make all clients exactly the same I don't expect this to happen and also believe that users are able to realize that different clients have different capabilities. Thanks for your comments! Cheers, Gunnar > > 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-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel -- ______ 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 << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From joon at radleys.co.za Tue Oct 16 10:19:04 2007 From: joon at radleys.co.za (Joon Radley) Date: Tue, 16 Oct 2007 10:19:04 +0200 Subject: [Kolab-devel] Declaring a new folder type for Horde preferences In-Reply-To: <87abqjzl6o.fsf@home.pardus.de> References: <87fy1kqa9n.fsf@home.pardus.de> <200710091503.00009.bernhard@intevation.de> <87odf84e3g.fsf@home.pardus.de> <200710151438.01493.bernhard@intevation.de> <87abqjzl6o.fsf@home.pardus.de> Message-ID: <001701c80fcd$3a35b610$aea12230$@co.za> Hi, > Back to the Kolab-compatible clients: Your suggestion is to limit the > type of folders we use to the set of folder types that are supported > by all clients declared Kolab-compliant. This also means to limit the > addition of features to the slowest progressing Kolab-compatible > client. I assume that we will thus be always slightly behind the > Microsoft product. You cannot limit the type of folders as custom folders are supported in Outlook. Kolab compliant clients should not display unknown folder types for that client and normal IMAP4 clients will see the Kolab client information body of the message. 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 From wrobel at pardus.de Tue Oct 30 10:57:48 2007 From: wrobel at pardus.de (Gunnar Wrobel) Date: Tue, 30 Oct 2007 10:57:48 +0100 Subject: IMAP annotation for groupware folder descriptions In-Reply-To: <200710091444.12655.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 9 Oct 2007 14:44:04 +0200") References: <87fy1kqa9n.fsf@home.pardus.de> <200709250710.01493.martin.konold@erfrakon.de> <000e01c7ff35$c1f559a0$45e00ce0$@co.za> <200710091444.12655.bernhard@intevation.de> Message-ID: <87odeggc0z.fsf@home.pardus.de> Bernhard Reiter 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 << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~