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

[Christian Mollekopf]

On 2012-03-09 15:41, Florian v. Samson wrote:
> 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.
>

Java bindings are certainly possible (since this is supported by SWIG), 
I'm not sure how to make JavaScript-bindings though.
It seems the v8 javascript engine supports this though. It's definitely 
an extra effort though, which I don't think we'll be doing.
I do think however that the effort for writing a wrapper is 
significantly lower than implementing everything form scratch, so I'd 
suggest to the synckolab people to look into how they can make use of 
this.

Also C-bindings cannot be directly generated, but writing a wrapper 
should be trivial.

We're definitely available to help, I don't think we can offer to do 
all the work though.

Obviously libkolabxml is open-source, so contributions are welcome too 
=)

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

I don't expect much more frequent changes than yearly, but we 
definitely would like to see a broad adoption of libkolabxml in all 
kinds of clients.
It can only help interoperability.

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

"Broken in many ways" is not how I see it, and yes, Kontact 2 (aka E5) 
is going to be our reference implementation.

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

Kontact 2 is doing the most sensible thing it can by using this 
property as OPACITY IMO,
because it's missing in kolabformat v2, respectively was replaced by 
show-time-as.

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

There is no Opacity in kolabformat v2. Not in the spec I have.

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

Personally I don't see this flying. This property is something Kolab 
specific, not mappable to anything in iCal, which is certainly bad for 
interoperability.
And the point on rebasing on xCal/iCal is exactly to get a format which 
is interoperable and can be supported by non Kolab-only clients.
It's of course possible that we end up adding it again, because it is 
indeed so tremendously important, and at this point we will have to 
evaluate how to model that notion in the storage format, but until then 
I'd like to stay away form such kolab-only properties.

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

Kontact2 will be ready.

Cheers,
Christian

-- 
Christian Mollekopf
Software Engineer

Kolab Systems AG
Zürich, Switzerland

e: mollekopf at kolabsys.com
w: http://kolabsys.com

pgp: EA657400 Christian Mollekopf