[Kolab-devel] Declaring a new folder type for Horde preferences
wrobel at pardus.de
Tue Oct 16 07:24:15 CEST 2007
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.
> 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
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
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!
> 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
______ 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 <<
More information about the format