From joon at radleys.co.za  Thu Nov  1 05:42:09 2007
From: joon at radleys.co.za (Joon Radley)
Date: Thu, 1 Nov 2007 06:42:09 +0200
Subject: [Kolab-devel] Declaring a new folder type for Horde preferences
In-Reply-To: <001701c80fcd$3a35b610$aea12230$@co.za>
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>
	<001701c80fcd$3a35b610$aea12230$@co.za>
Message-ID: <001201c81c41$938925f0$ba9b71d0$@co.za>

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




From wrobel at pardus.de  Thu Nov  1 08:45:38 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 01 Nov 2007 08:45:38 +0100
Subject: Features outside of the Kolab format
Message-ID: <87abpyv271.fsf@home.pardus.de>

Hi!

I have been analyzing cross Kolab client compatibility for the Kolab
Konsortium during the last weeks. I have been looking at the following
six clients:

 - Kontact
 - Outlook/Toltec
 - Outlook/Konsec
 - Outlook/Bynari
 - Thunderbird
 - Horde

This was focused on checking compatibility with Horde.

There is one obvious conclusion concerning the Kolab format
specification:

 It is extremely successful.

Besides some really minor bugs the clients have no problems talking
with each other since they all adhere to the format specs.

The downside:

 The Kolab format is limited.

Many clients by now offer features beyond what is specified within the
Kolab format.

What do developers do in case a Kolab client offers additional
features that are not being described within the Kolab format?

 They implement it.

This leads to the interesting situation that all the Outlook
connectors implement any groupware object attributes that lie outside
of the format specs in their own special way and are incapable of
understanding each other concerning those attributes. The same holds
true for the other clients in cases their feature set lies outside of
the specs. Horde may be an exemption from that but only because it
does not yet offer features left undefined by the Kolab format.

I think it would be good if the Kolab format development process would
better accommodate for the fact that clients progress and offer
features beyond the boundaries of the format specifications.

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  Fri Nov  2 12:17:33 2007
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Fri, 2 Nov 2007 12:17:33 +0100
Subject: RFC: drop requirement to set /vendor/kolab/folder-type: mail
Message-ID: <20071102111733.GA22309.thomas@intevation.de>

Hi!

Inspired by the regular problems with annotations.db I want to
suggest that the requirement to set /vendor/kolab/folder-type: mail
should be dropped as it does not give any additional information:

| All folders MUST be annotated with an entry /vendor/kolab/folder-type

| All Kolab clients MUST assume that folders without an explicit type
| set are email folders.

Because of this second requirement there will be no problems with
Kolab clients adhering to the old specs.

| All annotation MUST be set during the initial creation of a folder
| and cannot be altered afterwards.

This is an important requirement, but Kontact already fails here,
see kolab/issue2069 (Kontact rewrites custom folder types)

Regards,
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/20071102/5efd498c/attachment.bin

From martin.konold at erfrakon.de  Sat Nov  3 00:06:29 2007
From: martin.konold at erfrakon.de (Martin Konold)
Date: Sat, 3 Nov 2007 00:06:29 +0100
Subject: RFC: drop requirement to set /vendor/kolab/folder-type: mail
In-Reply-To: <20071102111733.GA22309.thomas@intevation.de>
References: <20071102111733.GA22309.thomas@intevation.de>
Message-ID: <200711030006.38041.martin.konold@erfrakon.de>

Am Freitag, 2. November 2007 schrieb Thomas Arendsen Hein:

Hi Thomas,

> Inspired by the regular problems with annotations.db I want to

I am wondering why you are using this argument. Basically since many months 
this problem is understood to be an already solved Linux kernel issue which 
additionally can be worked around when using berkley db instead of skiplist.

> suggest that the requirement to set /vendor/kolab/folder-type: mail
>
> should be dropped as it does not give any additional information:

It makes the spec explicit instead of implicit. In the future I am seriously 
considering to store even more meta information with the IMAP folder. E.g. it 
makes sense to store stuff like check-interval, PutRepliesInSameFolder, 
FolderIcon, CustomIcons,....

> | All folders MUST be annotated with an entry /vendor/kolab/folder-type
> |
> | All Kolab clients MUST assume that folders without an explicit type
> | set are email folders.
>
> Because of this second requirement there will be no problems with
> Kolab clients adhering to the old specs.

correct.

> | All annotation MUST be set during the initial creation of a folder
> | and cannot be altered afterwards.
>
> This is an important requirement, but Kontact already fails here,
> see kolab/issue2069 (Kontact rewrites custom folder types)

This is a bug.

Regards,
-- martin konold

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstra?e 23 Stuttgart - Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-format/attachments/20071103/c8379227/attachment.bin

From martin.konold at erfrakon.de  Sat Nov  3 00:08:53 2007
From: martin.konold at erfrakon.de (Martin Konold)
Date: Sat, 3 Nov 2007 00:08:53 +0100
Subject: Features outside of the Kolab format
In-Reply-To: <87abpyv271.fsf@home.pardus.de>
References: <87abpyv271.fsf@home.pardus.de>
Message-ID: <200711030008.58170.martin.konold@erfrakon.de>

Am Donnerstag, 1. November 2007 schrieb Gunnar Wrobel:

Hi Gunnar,

> I think it would be good if the Kolab format development process would
> better accommodate for the fact that clients progress and offer
> features beyond the boundaries of the format specifications.

I fully agree with your assessment! We need to identify the issues and then 
start to document and standardize them.

E.g. we could start with the "private" flag.

Mit freundlichen Gr??en,
-- martin konold

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstra?e 23 Stuttgart - Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-format/attachments/20071103/ab1f6b73/attachment.bin

From bernhard at intevation.de  Mon Nov  5 18:22:21 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 5 Nov 2007 18:22:21 +0100
Subject: Features outside of the Kolab format
In-Reply-To: <87abpyv271.fsf@home.pardus.de>
References: <87abpyv271.fsf@home.pardus.de>
Message-ID: <200711051822.24554.bernhard@intevation.de>

On Thursday 01 November 2007 08:45, Gunnar Wrobel wrote:
> The downside:
>
> ?The Kolab format is limited.

This can also be considered a strength.
To my eyes iCalendar has too many variants, 
keeping something simple and straight raises the chances 
to get it implemented in a good way.

> Many clients by now offer features beyond what is specified within the
> Kolab format.

As the clients are different, they will always have some features that do not 
fully match. Kolab tries to find one (out of several possible) common 
minimum-set.

> What do developers do in case a Kolab client offers additional
> features that are not being described within the Kolab format?
>
> ?They implement it.
>
> This leads to the interesting situation that all the Outlook
> connectors implement any groupware object attributes that lie outside
> of the format specs in their own special way and are incapable of
> understanding each other concerning those attributes. 

As far as I have understood there is the technical difficulty, 
that any Outlook plugin can add attributes to the internal Outlook message 
object. So the full set of possible attributes is not known.
For many users those plugins need to work, so one easy way is to save the 
message object somehow in a windows specific way.

> I think it would be good if the Kolab format development process would
> better accommodate for the fact that clients progress and offer
> features beyond the boundaries of the format specifications.

I agree, but I could also say: It already does. 
The main problem with format changes is client 
and server implementation support and most current clients 
seem to be conservative. 

The process is to convince a significant number of people with a proposal
to change the format over this list. 

Best,
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: smime.p7s
Type: application/pkcs7-signature
Size: 1571 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-format/attachments/20071105/962fa5dd/smime.bin

From bernhard at intevation.de  Mon Nov  5 18:29:54 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 5 Nov 2007 18:29:54 +0100
Subject: [Kolab-devel] Declaring a new folder type for Horde preferences
In-Reply-To: <001701c80fcd$3a35b610$aea12230$@co.za>
References: <87fy1kqa9n.fsf@home.pardus.de> <87abqjzl6o.fsf@home.pardus.de>
	<001701c80fcd$3a35b610$aea12230$@co.za>
Message-ID: <200711051829.55069.bernhard@intevation.de>

Gunnar, Joon,

On Tuesday 16 October 2007 10:19, Joon Radley wrote:
> 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.

as both of you are in favor, what about making this a SHOULD?
Like: Client SHOULD have an option to blend unknown folder-types away.

I am a bit worried that potential information is overlooked by a users
of a client, this is quite important for a good user experience using 
compatible clients.

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/20071105/900818ed/attachment.bin

From bernhard at intevation.de  Mon Nov  5 18:31:12 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 5 Nov 2007 18:31:12 +0100
Subject: Features outside of the Kolab format
In-Reply-To: <200711030008.58170.martin.konold@erfrakon.de>
References: <87abpyv271.fsf@home.pardus.de>
	<200711030008.58170.martin.konold@erfrakon.de>
Message-ID: <200711051831.13809.bernhard@intevation.de>

Hi Martin,

On Saturday 03 November 2007 00:08, Martin Konold wrote:
> E.g. we could start with the "private" flag.

I think this one might be too large to handle it as the first one.
Maybe we can start with an easier one that does not fundamentally
will influcence which data is displayed where.

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/20071105/5cc8f108/attachment.bin

From bernhard at intevation.de  Mon Nov  5 18:15:27 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 5 Nov 2007 18:15:27 +0100
Subject: IMAP annotation for groupware folder descriptions
In-Reply-To: <87odeggc0z.fsf@home.pardus.de>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200710091444.12655.bernhard@intevation.de>
	<87odeggc0z.fsf@home.pardus.de>
Message-ID: <200711051815.32558.bernhard@intevation.de>

Hi Gunnar,

On Tuesday 30 October 2007 10:57, Gunnar Wrobel wrote:
> But in general I believe it makes sense to use solutions that don't
> lock people down. 

we are on the same page here.

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

I would like to see more widespread use, but not at all costs.
The format itself is important to present a good groupware funcationality to 
users. If the group of client fully supporting it is small, it is easier
to improve the format and thus the groupware experience.
Kolab Server XML is designed to by a storage data format and to this extend it 
is internal to each one particular Kolab Solution setup.

Also the format comes along with more requirements for a Kolab Client 
to fullful. 

> 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 first feeling is to not add an additional method.
Choice is good in principle, but in this regard I would rather
have a higher burden for Kolab Clients and to not water down the brand.
Kolab2 compliant servers would need to implement the freebusy mechanism
and the incidences-for funcationality as well.

Best,
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/20071105/8ee5b50d/attachment.bin

From bernhard at intevation.de  Mon Nov  5 18:38:48 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 5 Nov 2007 18:38:48 +0100
Subject: How compatible should clients be? (was: [Kolab-devel] Declaring a new
	folder type for Horde preferences)
In-Reply-To: <87abqjzl6o.fsf@home.pardus.de>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200710151438.01493.bernhard@intevation.de>
	<87abqjzl6o.fsf@home.pardus.de>
Message-ID: <200711060108.58018.bernhard@intevation.de>

On Tuesday 16 October 2007 07:24, Gunnar Wrobel wrote:
> Bernhard Reiter <bernhard at intevation.de> 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.

Yes, but only up to a point.
It will always be a valid scenario to have regular IMAP client access
the Kolab Server.

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

There is a first MIME section which will give a user a nice hint,
so it is not that bad.

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

We should avoid the chance of collateral damage as good as we can.
A regular IMAP client should not cause trouble in normal operation.

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

I believe that Kolab is already ahead of the Microsoft product in some regards 
(in others we are behind), but the folder-types are crucial for it 
in my view. On the contrary, the design idea is to not make a bunch of 62% 
good client, but a few which are 96% there.

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

[See my other post.]

> 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?

Kontact always was a shell for "components" that together prodive the current 
functionality to the users. I am unsure about which recent chance you might 
refer to.

> 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?

Because a 96% client for a few tasks is better than a 62% client 
which does a lot more. The area of invitation emails and iTIP interaction
that Kolab Clients should be able to do is much more interesting to me
to develop the groupware capability.

Of course I am all for experiments if somebody likes to do them.
It is not necessary to hand out the Kolab compatible label for this, though.

> > 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?

I tried to give an example which you have cited: :)
>
> > 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.

I have made the experience, that this little potential 
for missunderstandings is a real. Keeping it simpler and chosing a good name
might be just enough. Users will need a way for out-of-band communication 
anyway and good add description for folders there as well.

If we can find IMAP clients that use the /comment feature,
I am not fully opposed to the feature tough.
I would love to see some stats about what people are using these comments
or folder-descriptions for, though.

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

Making the clients all the same is not the goal. Having a minimum groupware 
functionality that you can rely on, if you read "Kolab" is.

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


From joon at radleys.co.za  Tue Nov  6 06:03:48 2007
From: joon at radleys.co.za (Joon Radley)
Date: Tue, 6 Nov 2007 07:03:48 +0200
Subject: [Kolab-devel] Declaring a new folder type for Horde preferences
In-Reply-To: <200711051829.55069.bernhard@intevation.de>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<87abqjzl6o.fsf@home.pardus.de>	<001701c80fcd$3a35b610$aea12230$@co.za>
	<200711051829.55069.bernhard@intevation.de>
Message-ID: <000901c82032$6d7bc260$48734720$@co.za>

Hi Bernhard,

> as both of you are in favor, what about making this a SHOULD?
> Like: Client SHOULD have an option to blend unknown folder-types away.

I have no problem with this. It was originally the idea that a client could
determine the folder type by looking at the annotation and the deciding if
it wanted to display it or not.

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 Bernhard Reiter
> Sent: 05 November 2007 07:30 PM
> To: kolab-format at kolab.org
> Subject: Re: [Kolab-devel] Declaring a new folder type for Horde
> preferences
> 
> Gunnar, Joon,
> 
> On Tuesday 16 October 2007 10:19, Joon Radley wrote:
> > 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.
> 
> as both of you are in favor, what about making this a SHOULD?
> Like: Client SHOULD have an option to blend unknown folder-types away.
> 
> I am a bit worried that potential information is overlooked by a users
> of a client, this is quite important for a good user experience using
> compatible clients.
> 
> 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




From wrobel at pardus.de  Tue Nov  6 14:46:07 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 06 Nov 2007 14:46:07 +0100
Subject: [Kolab-devel] Declaring a new folder type for Horde preferences
In-Reply-To: <200711051829.55069.bernhard@intevation.de> (Bernhard Reiter's
	message of "Mon, 5 Nov 2007 18:29:54 +0100")
References: <87fy1kqa9n.fsf@home.pardus.de> <87abqjzl6o.fsf@home.pardus.de>
	<001701c80fcd$3a35b610$aea12230$@co.za>
	<200711051829.55069.bernhard@intevation.de>
Message-ID: <87d4unmqqo.fsf@home.pardus.de>

A non-text attachment was scrubbed...
Name: Kolab-ignore_unkown_folders.patch
Type: text/x-patch
Size: 860 bytes
Desc: Format patch
Url : http://kolab.org/pipermail/kolab-format/attachments/20071106/572a6376/Kolab-ignore_unkown_folders.bin
-------------- next part --------------


>
> I am a bit worried that potential information is overlooked by a users
> of a client, this is quite important for a good user experience using 
> compatible clients.
>
> 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 wrobel at pardus.de  Tue Nov  6 15:27:29 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 06 Nov 2007 15:27:29 +0100
Subject: Features outside of the Kolab format
In-Reply-To: <200711051822.24554.bernhard@intevation.de> (Bernhard Reiter's
	message of "Mon, 5 Nov 2007 18:22:21 +0100")
References: <87abpyv271.fsf@home.pardus.de>
	<200711051822.24554.bernhard@intevation.de>
Message-ID: <878x5bmotq.fsf@home.pardus.de>

Bernhard Reiter <bernhard at intevation.de> writes:

> On Thursday 01 November 2007 08:45, Gunnar Wrobel wrote:
>> The downside:
>>
>> ?The Kolab format is limited.
>
> This can also be considered a strength.
> To my eyes iCalendar has too many variants, 
> keeping something simple and straight raises the chances 
> to get it implemented in a good way.
>

Of course.

>> Many clients by now offer features beyond what is specified within the
>> Kolab format.
>
> As the clients are different, they will always have some features that do not 
> fully match. Kolab tries to find one (out of several possible) common 
> minimum-set.

Fine with me.

>
>> What do developers do in case a Kolab client offers additional
>> features that are not being described within the Kolab format?
>>
>> ?They implement it.
>>
>> This leads to the interesting situation that all the Outlook
>> connectors implement any groupware object attributes that lie outside
>> of the format specs in their own special way and are incapable of
>> understanding each other concerning those attributes. 
>
> As far as I have understood there is the technical difficulty, 
> that any Outlook plugin can add attributes to the internal Outlook message 
> object. So the full set of possible attributes is not known.
> For many users those plugins need to work, so one easy way is to save the 
> message object somehow in a windows specific way.
>
>> I think it would be good if the Kolab format development process would
>> better accommodate for the fact that clients progress and offer
>> features beyond the boundaries of the format specifications.
>
> I agree, but I could also say: It already does.

I fail to see that :)

> The main problem with format changes is client 
> and server implementation support and most current clients 
> seem to be conservative. 
>

I didn't make myself clear enough: I don't want to change the core
Kolab format itself. I don't want it to cope with every little client
feature I can think of.

> The process is to convince a significant number of people with a proposal
> to change the format over this list. 

This is also okay.

All I want is to allow format extensions and REQUIRE their declaration.

I suggest to add a line in the Kolab format specs that says that a
client MAY NOT extend the format with custom additions UNLESS they are
being announced on this list and stored on a wiki page for further
reference. If the client violates that it is no longer a Kolab
compliant client.

I fail to see how the Kolab format deals in an appropriate way with
extensions at the moment. The clients by now start to move into areas
left undefined by the Kolab format. As you already mentioned this is
bound to happen.

In most cases these extensions are not being announced. But even if
they are it is unlikely that they are being included into the format.

Look at my posts suggesting a new way on handling the Horde
preferences: While this found a conclusion and the preferences will
continue to be stored in LDAP this does not change the fact that I
have a need for the IMAP based driver. Of course I'm unable to get
this into the format so what will I do? I'll probably add it as an
optional module anyhow in Horde without ever bothering about the
format specs.

The few customized attributes that have been added to Kontact and
Outlook are mentioned nowhere at all. The reason is simple: As a
client developer the effort is significantly reduced by just
implementing new features without bothering about long discussions on
this list.

But in the long run this causes compatibility problems. If I'd like to
add a "blog feed" attribute to contacts in Horde and I never used
Kontact before, how should I know that Kontact already uses an
internal definition for this attribute? If I'd like to use a "company"
attribute on a task I could by now choose between three different
implementations from three different Outlook connectors. Or I might
implement all three :)

If these things would be public it would be far easier to keep the
other clients compatible even if these extension are not an integral
part of the Kolab format.

Cheers,

Gunnar

> Best,
> 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 wrobel at pardus.de  Tue Nov  6 15:29:05 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 06 Nov 2007 15:29:05 +0100
Subject: IMAP annotation for groupware folder descriptions
In-Reply-To: <200711051815.32558.bernhard@intevation.de> (Bernhard Reiter's
	message of "Mon, 5 Nov 2007 18:15:27 +0100")
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200710091444.12655.bernhard@intevation.de>
	<87odeggc0z.fsf@home.pardus.de>
	<200711051815.32558.bernhard@intevation.de>
Message-ID: <874pfzmor2.fsf@home.pardus.de>

Bernhard Reiter <bernhard at intevation.de> writes:

> Hi Gunnar,
>
> On Tuesday 30 October 2007 10:57, Gunnar Wrobel wrote:
>> But in general I believe it makes sense to use solutions that don't
>> lock people down. 
>
> we are on the same page here.
>
>> 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.
>
> I would like to see more widespread use, but not at all costs.
> The format itself is important to present a good groupware funcationality to 
> users. If the group of client fully supporting it is small, it is easier
> to improve the format and thus the groupware experience.
> Kolab Server XML is designed to by a storage data format and to this extend it 
> is internal to each one particular Kolab Solution setup.
>
> Also the format comes along with more requirements for a Kolab Client 
> to fullful. 
>
>> 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 first feeling is to not add an additional method.
> Choice is good in principle, but in this regard I would rather
> have a higher burden for Kolab Clients and to not water down the brand.
> Kolab2 compliant servers would need to implement the freebusy mechanism
> and the incidences-for funcationality as well.

I don't want to require the clients to implement this. I just think it
would be a desireable extension. Especially for Horde.

Cheers,

Gunnar

>
> Best,
> 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 wrobel at pardus.de  Tue Nov  6 15:38:01 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 06 Nov 2007 15:38:01 +0100
Subject: How compatible should clients be?
In-Reply-To: <200711060108.58018.bernhard@intevation.de> (Bernhard Reiter's
	message of "Mon, 5 Nov 2007 18:38:48 +0100")
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200710151438.01493.bernhard@intevation.de>
	<87abqjzl6o.fsf@home.pardus.de>
	<200711060108.58018.bernhard@intevation.de>
Message-ID: <87zlxrl9rq.fsf@home.pardus.de>

Bernhard Reiter <bernhard at intevation.de> writes:

> On Tuesday 16 October 2007 07:24, Gunnar Wrobel wrote:
>> Bernhard Reiter <bernhard at intevation.de> 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.
>
> Yes, but only up to a point.
> It will always be a valid scenario to have regular IMAP client access
> the Kolab Server.
>
>> > 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.
>
> There is a first MIME section which will give a user a nice hint,
> so it is not that bad.
>
>> 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.
>
> We should avoid the chance of collateral damage as good as we can.
> A regular IMAP client should not cause trouble in normal operation.
>
>> 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.
>
> I believe that Kolab is already ahead of the Microsoft product in some regards 
> (in others we are behind), but the folder-types are crucial for it 
> in my view. On the contrary, the design idea is to not make a bunch of 62% 
> good client, but a few which are 96% there.
>
>> 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.
>
> [See my other post.]
>
>> 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?
>
> Kontact always was a shell for "components" that together prodive the current 
> functionality to the users. I am unsure about which recent chance you might 
> refer to.

I'm not too deep in Kontact development so maybe I misunderstood
something there. I though it got significantly easier to add plugins
from other apps.

>
>> 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?
>
> Because a 96% client for a few tasks is better than a 62% client 
> which does a lot more. The area of invitation emails and iTIP interaction
> that Kolab Clients should be able to do is much more interesting to me
> to develop the groupware capability.
>
> Of course I am all for experiments if somebody likes to do them.
> It is not necessary to hand out the Kolab compatible label for this, though.

That is all I'm asking for. The possibility to experiment. As long as
I'm free to declare new folder types and new data types stored in XML
I'm happy :) No need to brand them with "Kolab" at all.

Cheers,

Gunnar

>
>> > 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?
>
> I tried to give an example which you have cited: :)
>>
>> > 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.
>
> I have made the experience, that this little potential 
> for missunderstandings is a real. Keeping it simpler and chosing a good name
> might be just enough. Users will need a way for out-of-band communication 
> anyway and good add description for folders there as well.
>
> If we can find IMAP clients that use the /comment feature,
> I am not fully opposed to the feature tough.
> I would love to see some stats about what people are using these comments
> or folder-descriptions for, though.
>
>> 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.
>
> Making the clients all the same is not the goal. Having a minimum groupware 
> functionality that you can rely on, if you read "Kolab" is.
>
> 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 Nov  6 19:05:52 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 6 Nov 2007 19:05:52 +0100
Subject: [Kolab-devel] Declaring a new folder type for Horde preferences
In-Reply-To: <87d4unmqqo.fsf@home.pardus.de>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200711051829.55069.bernhard@intevation.de>
	<87d4unmqqo.fsf@home.pardus.de>
Message-ID: <200711061905.53593.bernhard@intevation.de>

On Tuesday 06 November 2007 14:46, Gunnar Wrobel wrote:
>  as both of you are in favor, what about making this a SHOULD?
>
> > Like: Client SHOULD have an option to blend unknown folder-types away.
>
> Fine with me too.
>
> I attached a suggested patch for the format definition.


I think it should be worded like I did above and mention
that there "SHOULD be an option to blend out" ...

> This patch also changes the example for non standardized kolab folder
> names from "kolab.o-voicemail" to "o-voicemail". I did this because I
> lack an explanation for the "kolab.*" prefix and I think it confuses
> the "TYPE" and "SUBTYPE" concept for the entries. The specific
> "kolab"-TYPE is mentioned nowhere else.

I believe you are right in changing this, but we should make it a different 
proposed change.
Also the proposed patches should include chanced to the "revision" part
of the document. Please commit the removal of "kolab.*" prefix I think this is 
a bug.

Also I believe that we should make this as a change for Kolab Format 2.1 
development. Thus we should conclude and release 2.0 and call it final.
I have to review some of the later changes for this.

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/20071106/328eaca5/attachment.bin

From bernhard at intevation.de  Tue Nov  6 19:11:27 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 6 Nov 2007 19:11:27 +0100
Subject: Features outside of the Kolab format
In-Reply-To: <878x5bmotq.fsf@home.pardus.de>
References: <87abpyv271.fsf@home.pardus.de>
	<200711051822.24554.bernhard@intevation.de>
	<878x5bmotq.fsf@home.pardus.de>
Message-ID: <200711061911.28486.bernhard@intevation.de>

On Tuesday 06 November 2007 15:27, Gunnar Wrobel wrote:
> All I want is to allow format extensions and REQUIRE their declaration.
>
> I suggest to add a line in the Kolab format specs that says that a
> client MAY NOT extend the format with custom additions UNLESS they are
> being 

You are raising questions of procedures - rightfully. 
However I will have to think about the answers a little bit more
and the possible consequences of your proposal.
All in all I am a bit reluctant to  overhaul the process 
to make it very easy to change the format.

> announced on this list and stored on a wiki page for further
> reference. If the client violates that it is no longer a Kolab
> compliant client.

The problem with the announcement of the list and storage of the wiki page is 
quite weak and this makes complicancy hard to control.

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/20071106/6d3c6d39/attachment.bin

From bernhard at intevation.de  Tue Nov  6 19:13:25 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 6 Nov 2007 19:13:25 +0100
Subject: How compatible should clients be?
In-Reply-To: <87zlxrl9rq.fsf@home.pardus.de>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200711060108.58018.bernhard@intevation.de>
	<87zlxrl9rq.fsf@home.pardus.de>
Message-ID: <200711061913.26600.bernhard@intevation.de>

On Tuesday 06 November 2007 15:38, Gunnar Wrobel wrote:
> > Of course I am all for experiments if somebody likes to do them.
> > It is not necessary to hand out the Kolab compatible label for this,
> > though.
>
> That is all I'm asking for. The possibility to experiment. As long as
> I'm free to declare new folder types and new data types stored in XML
> I'm happy :) No need to brand them with "Kolab" at all.

No one keeps you from doing to for experiments of course.
I suggest that you keep an option to enable and disable those experiments
in a client.

-- 
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/20071106/dfae44f6/attachment.bin

From bernhard at intevation.de  Tue Nov  6 19:19:27 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 6 Nov 2007 19:19:27 +0100
Subject: IMAP annotation for groupware folder descriptions
In-Reply-To: <874pfzmor2.fsf@home.pardus.de>
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200711051815.32558.bernhard@intevation.de>
	<874pfzmor2.fsf@home.pardus.de>
Message-ID: <200711061919.28644.bernhard@intevation.de>

On Tuesday 06 November 2007 15:29, Gunnar Wrobel wrote:
> >> 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 first feeling is to not add an additional method.
> > Choice is good in principle, but in this regard I would rather
> > have a higher burden for Kolab Clients and to not water down the brand.
> > Kolab2 compliant servers would need to implement the freebusy mechanism
> > and the incidences-for funcationality as well.
>
> I don't want to require the clients to implement this. I just think it
> would be a desireable extension. Especially for Horde.

This is always a difficult strategic decision.

I would not make this "optional" for Kolab Clients, because the user
will not get a full Kolab experience unless the server supports
freebusy generation and some other stuff. The servers that want to do this,
can do so quite easily including the ANNOTATEMORE extension.
Client can implement anything optional, but it would not be Kolab I guess.
I hope that we can increase the pressure to actually lobby for a standard way
to save additional information for a folder. ANNOTATEMORE seems good for this 
purpose and we have a leading IMAP server implementing it already. 
It would be possible to create patches for the others. 
As with many extensions this has proven useful and the more people
that realise the pressure to include it in other implementation will grow.

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/20071106/d9f3c477/attachment.bin

From wrobel at pardus.de  Tue Nov 13 16:01:15 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 13 Nov 2007 16:01:15 +0100
Subject: Features outside of the Kolab format
In-Reply-To: <200711061911.28486.bernhard@intevation.de> (Bernhard Reiter's
	message of "Tue, 6 Nov 2007 19:11:27 +0100")
References: <87abpyv271.fsf@home.pardus.de>
	<200711051822.24554.bernhard@intevation.de>
	<878x5bmotq.fsf@home.pardus.de>
	<200711061911.28486.bernhard@intevation.de>
Message-ID: <87lk92mbpg.fsf@home.pardus.de>

Bernhard Reiter <bernhard at intevation.de> writes:

> On Tuesday 06 November 2007 15:27, Gunnar Wrobel wrote:
>> All I want is to allow format extensions and REQUIRE their declaration.
>>
>> I suggest to add a line in the Kolab format specs that says that a
>> client MAY NOT extend the format with custom additions UNLESS they are
>> being 
>
> You are raising questions of procedures - rightfully. 
> However I will have to think about the answers a little bit more
> and the possible consequences of your proposal.
> All in all I am a bit reluctant to  overhaul the process 
> to make it very easy to change the format.
>
>> announced on this list and stored on a wiki page for further
>> reference. If the client violates that it is no longer a Kolab
>> compliant client.
>
> The problem with the announcement of the list and storage of the wiki page is 
> quite weak and this makes complicancy hard to control.

That is true. But I do not really want to consider such announcements
as binding.

I'm currently converting the Horde Trean application to Kolab. This
will at some point allow to store your Bookmarks on the server. I'll
also define an experimental XML format for storing the Bookmark
information.

I think it is useful to the other clients if I am forced to publicly
announce and describe this format before actually using. At that point
other devs would certainly join the discussion an tell what they
consider bad about my new format. This has a benefit for me since I
can improve it and on the other hand it helps the community because
that way the other devs won't have to find out about custom formats by
testing the other software themselves. At that point it will usually
be too late to move back in time and revert the borked format.

So by disallowing to call a Kolab client that uses unpublished custom
formats as Kolab compliant I just want to increase discussions about
such features.

I believe it would have helped if one of the Outlook connector devs
would have for example declared a new "company" attribute on tasks
earlie on. Maybe the other Outlook connector devs would have also used
that format instead of choosing their own.

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-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 wrobel at pardus.de  Tue Nov 13 16:07:45 2007
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 13 Nov 2007 16:07:45 +0100
Subject: IMAP annotation for groupware folder descriptions
In-Reply-To: <200711061919.28644.bernhard@intevation.de> (Bernhard Reiter's
	message of "Tue, 6 Nov 2007 19:19:27 +0100")
References: <87fy1kqa9n.fsf@home.pardus.de>
	<200711051815.32558.bernhard@intevation.de>
	<874pfzmor2.fsf@home.pardus.de>
	<200711061919.28644.bernhard@intevation.de>
Message-ID: <87abpimbem.fsf@home.pardus.de>

Bernhard Reiter <bernhard at intevation.de> writes:

> On Tuesday 06 November 2007 15:29, Gunnar Wrobel wrote:
>> >> 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 first feeling is to not add an additional method.
>> > Choice is good in principle, but in this regard I would rather
>> > have a higher burden for Kolab Clients and to not water down the brand.
>> > Kolab2 compliant servers would need to implement the freebusy mechanism
>> > and the incidences-for funcationality as well.
>>
>> I don't want to require the clients to implement this. I just think it
>> would be a desireable extension. Especially for Horde.
>
> This is always a difficult strategic decision.
>
> I would not make this "optional" for Kolab Clients, because the user
> will not get a full Kolab experience unless the server supports
> freebusy generation and some other stuff. 

Okay, that is true.

> The servers that want to do this,
> can do so quite easily including the ANNOTATEMORE extension.
> Client can implement anything optional, but it would not be Kolab I guess.
> I hope that we can increase the pressure to actually lobby for a standard way
> to save additional information for a folder. ANNOTATEMORE seems good for this 
> purpose and we have a leading IMAP server implementing it already. 

The METADATA extension is certainly the right solution for our
purposes. I won't disagree. I just have the feeling that having Cyrus
supporting this for the last few years did not really help in getting
this forward.

> It would be possible to create patches for the others. 
> As with many extensions this has proven useful and the more people
> that realise the pressure to include it in other implementation will grow.

Okay, maybe I'm just being impatient :) After all this is a major
problem for on a distro like Gentoo.

Anyway I'll try to get this implemented into Horde at some point since
I'd really like to see people storing their Groupware data on Google
Mail in a Kolab format. I guess we'd find some users for that :)

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