Rationale of the KEP2 design: central in-format TZ-data vs. individual local TZ-databases and more (Part 2)

[Bernhard Reiter]

Hi Florian, Georg,

I am hijacking this thread to discuss whether we want the
tz-data within an object (a) 
or outside in a database accessible by the client (b).

(a) was called "in-format" before and also "static" because
    of the tz-data being static to the object itself
(b) was also called "dynamic" because the tz-data in the database
    can change without the object being rewritten

I do not care much how we call it, as long as we know what we mean.
In my response I am trying to understand what is meant as good as possible.

Am Dienstag, 22. März 2011 11:48:27 schrieb Florian v. Samson:
> > So my question would be: From which source do you
> > obtain updates?
>
> I clearly answered that: Any source, which is providing sufficient data,
> e.g. the web-service you named more than once.

The webservice would be a variant of (b) and to make it mandatory would
make it harder to write offline capable clients. Also I do not think many
of those webservice already exist. Kolab Server would probably then need to 
provide one, which is some work away. 

> > for instance, or where clients do not have write access,

In a situation of a) I believe it is a problem if clients to now have write
access, they would be forced to display the appointment at the wrong time
until one of the writing clients updates it.

> They sure cannot update (logically), but I cannot see any reasons, why they
> should hinder the Kolab-object from being updated or read any updated
> Kolab-objects.

The problem is the time until one of the writing clients corrects the tz-date
inside of the object with a). With b), once the reading client has the new 
database, it can display the correct time.

> > or how do you prevent editing wars between clients who both
> > "know better"?
>
> I did answer that: by the help of a time-stamp.

In case of a), the time stamp or revision number would need to construct a 
linar progressing order of tz-data revisions to be able the let the client 
decide. As far as I can tell, by a short inspection, the tz-data by Olson 
does not provide such a version number. There is something which looks like 
version numbers for single zone files, but they do not seem to be a 
documented part of the interface, so I would not rely on them. In addition 
this revision number does not seem to be handled up to the higher level of 
timezone using data.

Client cannot construct the timestamp by themself.
If it would use the creation date of the event, that does not work, because a 
client with an older datebase might just write the object.
If it would use the update date of the Olson database in its system, 
this also could be off compared with a distribution where a newer Olson 
database was incorporated earlier.

> > And if you store both TZ-ID
> > and static, which of them is authoritative, and how do you enforce that?
>
> I still do not understand what "storing static" is supposed to mean
> precisely, as I am still not aware of any explanation.

What Georg refers to is: if with (a) you have a tz-data within the object
that does not match the tz-data of the tzid in my local database I am using 
as a client, which one should I follow, the TZ-ID in the object or the tz-data
in the object? This is what you have proposed to solve with a time-stamp, 
which I think does not work (see above). 

-- 
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/20110322/e1ec94af/attachment.sig>