How compatible should clients be?

[Gunnar Wrobel]

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