[NEW KEP] KEP #17: Kolab XML Format 3.0

Florian v. Samson florian.samson at bsi.bund.de
Fri Mar 9 15:41:02 CET 2012


Hi Christian,

Am Freitag, 9. März 2012, 11:37 schrieb Christian Mollekopf:
> On 2012-03-08 19:28, Florian v. Samson wrote:
> >
> > On to our conversation:
> >> We can add this at a later stage as a new optional property of the
> >> format.
> >
> > No, not realistically!
> > Technically you sure can, practically each change to the
> > Kolab-Format will leave most of its clients behind for a long time.
> > Or is Kolabsys planning to take care of patching ~10 Kolab-Clients
> > (see
> > <http://www-old.kolab.org/about-kolab-clients.html>) each time the
> > Format changes?
>
> With libkolabxml we make it very easy for every vendor to update his
> implementation.

For libkolabxml being useful for other clients (which would be very 
helpful), a couple of language-bindings are missing,
e.g.:
- C-bindings for evolution-kolab (rsp. Evolution-Data-Server (EDS))
- JavaScript-bindings for synckolab
- Java-bindings for Kolab-WS
- Etc.

> We maintain our main clients (Kontact, Roundcube, ....).

Sure, I did not seriously expect more than that.  Hence, sorry that I 
missed to mark above statement with a winking Smiley.

> > So practically I suggest: Take your time, aim well, you got a
> > single shot.
>
> Not really, but we also shouldn't change the format ever week, to
> that extend I agree.

Well, while "a single shot" was surely overdone (on purpose), with a 
broad rage of language-bindings for libkolabxml you may really change 
the Kolab3-Format every couple of months, without any fall-out.
But as long as these language-bindings are missing, you would implicitly 
work towards actively reducing the number of Kolab-clients when changes 
to the Kolab3-Format happen more frequently than yearly.

> >> Of course all clients need to be upgraded if the new format
> >> is used in a Kolab environment, otherwise the property would 
> >> of course be deleted again. (if the client overwrites an object 
> >> with a newer version of the format, which is bad behavior)
> >> and map free to
> >> "TRANSPARENT" and the other three to "OPAQUE" (for the
> >> conversion of existing properties of this type).
> >> >
> >> > As stated: these two setting are IMHO and memory mostly
> >> > unrelated, as they express different things.
> >> > You can employ such a mapping between them, but to me this is
> >> > like mapping a small set of pretty different colours (e. g. red,
> >> > green, blue, yellow) to black & white (no shades of grey):
> >> > feasible, but the outcome may be surprising.
> >>
> >> I get your point and can see the additional information expressed
> >> by this setting, but:
> >>
> >> - The setting is only valid if the opacity is set to OPAQUE,
> >
> > Yes.
> >
> >> and we
> >> should try to avoid such conditional settings as far as possible,
> >> because they add a lot of complexity to the format.
> >
> > While I agree to the "try", I do not to the "as far as possible"
> > and especially not to "they add a lot of complexity to the format".
> > There are far more complex things in the format.
>
> Not if we're talking about the writing/reading of the format. That
> interpreting recurrences is more complicated is clear.
>
> >> - Kolab Format v2 used this as a replacement for the OPACITY
> >> setting,
> >> so the potential for conflicting use of the property is high.
>
> I have that information from the Kontact implementation (master, not
> e3).

Well that version of Kontact is functionality reduced and broken in many 
ways compared to Kontact-E35.  Kontact2 cannot serve as a reference in 
its current state.

> > I am not sure that is correct, as I cannot find any such statement
> > in chapter 4 of the Kolab2-Format.  Maybe I just did not find it?

So you are now saying that the Kolab Format v2 does not use this as a 
replacement for the OPACITY setting, it is just Kontact2 doing this.
Well, Kontact2 is well known not to conform to the Kolab2-Format, so 
this very well could be just another defect of Kontact2.

> > Even if so, it is clearly a misuse, which regularly confuses users.
>
> It's not a misuse, it's just a reduced use as this property is not
> actually mappable to iCal, which is what Kontact is based on.

I disagree. It is a misuse, as another setting exists explicitly and 
solely for that: Opacity.

> >> - I don't know of any real usecase of the setting. I understand
> >> that there is a potential usecase, but I don't believe it's overly
> >> useful
> >
> > Oh, there is, definitely: I can note some, if I have time to
> > properly think them through, again, and to write them down, if that
> > really is helpful for you (please say so, then).
>
> I don't doubt that there are usecases. I just think we can do
> without.

Better don't, as many (at different Kolab installations) have requested 
both settings to work as one would expected (again and again, over 
years), as it serves their use-cases well. It has been right in front 
of their eyes for so may years now, and they have been hoping for an 
improvement for so long, that ultimately taking away this setting must 
lead to utter frustration.

> >> and don't know of any user-interface where this setting is
> >> actually exposed.
> >
> > In Kontact, and other PIM-clients.
> > That is actually causing the confusion: People expect both settings
> > to do something, but in practise they seem to influence things not 
> > at all, or rather erratic ways. Too many things are broken around 
> > F/B-lists to easily test that.
>
> So I suppose we're better off removing that "feature".

Absolutely not IMO, as noted above.
A proper specification, especially of these behavioural aspects, and a 
working reference implementation would be a huge step forward towards 
achieving customer satisfaction with regard to Free-/Busy-Lists. 
IOW, please do this right this time (and hence for the first time), 
instead of stripping valuable features, which did and do make sense for 
users, if only they would be working as expected.

> >> It's not in Kontact or Roundcube for sure.
> >
> > That is definitely not true: It has been in all Kontact versions,
> > which
> > are or have been productively usable (Proko2, E35).
> > (See also attached Kontact-E35 screenshot.)
>
> Ok, I was talking of the current KDE version (KDEPIM 4.8.1). So no
> client which will be upgraded to the new format in the near future
> will have a UI for this,

Ups, you are planning to release Kolab3 without a properly working (i.e. 
production-ready) reference-client?!? IMO, a bad idea. (Roundcube 
cannot really serve as a reference-client, as it lacks 
offline-capability, which is crucial for a Kolab reference-client.) 
Or are you planning a major overhaul of Kontact2 as well, which is 
finished, until Kolab3 is released?

> and I don't expect that to change anytime soon as this is a
> Kolab-only feature (it's not in iCal).
>
> >> So I reckon it has been used as a replacement of OPACITY anyways.
> >
> > No.

Cheers
	Florian




More information about the format mailing list