format compatibility (was: Timezone / recurrence scheduling discussion for Kolab)

[Bernhard Reiter]

Am Mittwoch, 10. November 2010 14:44:16 schrieb Jeroen van Meeuwen (Kolab 
Systems):
> > Note that a number of elder clients will not interpret a Kolab object
> > with a version number that is greater than 1. So it is a massive problem
> > when introducing new clients into old installations where old client with
> > this behaviour are still present. So avoiding this kind of change if
> > there is a different path is certainly a good idea.
>
> May I ask which such older clients are still under full and complete
> support?

I knew that Toltec 2 once had that behaviour and I do not know what Kontact
in the different varieties does. It sure is a risk to just interpret
a dataformat that you know you did not know when you were implementing your 
client, so I understand the issue for clients.
Toltec 2 is under full and complete support as far as I know. 

To be precise we probably would need to check with several clients, but I am 
not entirely sure what a client should do when he sees a new format revision.
They cannot know what the rules are for the new format, so there is a danger
of missinterpretation if they try to read and display what they understand,
the timezone issue is a good example for this.

> I suppose there is no chance to fix these older clients, or to get 
> rid of these older clients?

In a specific large installation the way seems to be to update all client at 
once or have a migration period where the new clients can deal with the new 
format, but write the old format until all clients are migrated.

Now count in that with larger installations clients sometimes are kept for a 
long time for a variety of reasons. They probably should not be, but 
sometimes they are kept still and breaking them without a good purpose might 
leave some users unhappy, especially larger organisational type of users. 

> I suppose any further development we can think of solving the original
> issue could result in these older clients being a blocker, and the fully
> backwards compatible solution might therefor end up being a band-aid
> solution on behalf of these older clients... a band-aid solution which then
> in turn would become a hurdle later on... but unless I know which clients
> we are talking about, I can't really make any such statement.

Yes it is a general issue, probably the behaviour in cases of new format specs
should be clarified better for the future. It seems a good idea to plan for a 
migration period anyway and a long time before the default is switched to the 
new format. 

I agree that we must find a way forward and be able to break backwards 
compatibility in important cases to avoid collecting cruft. 

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101110/cb5a4bca/attachment.sig>