IETF Logo Mail Archive

Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

Lester Caine <lester@lsces.co.uk> Mon, 15 December 2014 20:33 UTC

Return-Path: <lester@lsces.co.uk>
X-Original-To: tzdist@ietfa.amsl.com
Delivered-To: tzdist@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010671A8958 for <tzdist@ietfa.amsl.com>; Mon, 15 Dec 2014 12:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNr_ntSZ4jdE for <tzdist@ietfa.amsl.com>; Mon, 15 Dec 2014 12:33:26 -0800 (PST)
Received: from mail4.serversure.net (mail4-2.serversure.net [217.147.176.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606FE1A7008 for <tzdist@ietf.org>; Mon, 15 Dec 2014 12:33:25 -0800 (PST)
Received: (qmail 29874 invoked by uid 89); 15 Dec 2014 20:33:23 -0000
Received: by simscan 1.3.1 ppid: 29867, pid: 29870, t: 0.0935s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677
Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.178.188.220) by mail4.serversure.net with ESMTPA; 15 Dec 2014 20:33:23 -0000
Message-ID: <548F4592.5080508@lsces.co.uk>
Date: Mon, 15 Dec 2014 20:33:22 +0000
From: Lester Caine <lester@lsces.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tzdist@ietf.org
References: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <5488973F.7050400@andrew.cmu.edu> <54889C39.1080103@lsces.co.uk> <D2BE5C3BFE11019ECF4BEF62@caldav.corp.apple.com> <5488A6E6.8050903@lsces.co.uk> <CADC+-gTiyJ4QHZT6m3je9M9-ifSELnSWgmgy7iXSWNS+p8pthg@mail.gmail.com> <5488C0EA.8090505@lsces.co.uk> <CADC+-gTgckSe1ca6Sai6RguQid=ReM7bH6K8+dVVFm-YfbpFbA@mail.gmail.com> <5488DA56.2090306@lsces.co.uk> <CADC+-gQN=Qb2y8M-bHnPzMcK8r=xUG-seQ7XzvZwwcWsHpHnBQ@mail.gmail.com> <54895986.6060806@lsces.co.uk> <5489CA90.1070307@gmail.com> <35BC5886C9A58F866E8A46A8@caldav.corp.apple.com> <5489D9F7.3080207@gmail.com> <D196D63077FEC1B090DF7C86@caldav.corp.apple.com> <5489F79E.4080909@gmail.com> <BC19CC6916DC0E59CA63737D@caldav.corp.apple.com> <548B929C.3010505@gmail.com> <548C04F8.30005@lsces.co.uk> <D0F712C2A7EF425A8887E231@cyrus.local> <548C8535.5060508@cs.ucla.edu> <5F5A838C3A2D2B962EB84B92@cyrus.local> <548DEF42.8000300@cs.ucla.edu> <A895EB0A0055A08DA80F49B6@caldav.corp.apple.com>
In-Reply-To: <A895EB0A0055A08DA80F49B6@caldav.corp.apple.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/LHbophs3A68CsDVX63h7fdfLrRg
Subject: Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data
X-BeenThere: tzdist@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <tzdist.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist>, <mailto:tzdist-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tzdist/>
List-Post: <mailto:tzdist@ietf.org>
List-Help: <mailto:tzdist-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist>, <mailto:tzdist-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 20:33:28 -0000

On 15/12/14 19:15, Cyrus Daboo wrote:
> The complexity is all being added by the apparent need for versioning. I
> still contend that is unnecessary for tzdist. It is a problem for the
> consumers of the tzdist data and tzdist itself provides sufficient
> meta-data for them to deal with that.

There are race conditions that can only be identified by the correct use
of versions. These are currently totally unmanaged and if tzdist is
released retaining these problems, that fact has to be documented
properly. Something that the current draft simply ignores.

I don't see how a proper management of the publication of data makes
things complicated. It is simply that some users will never ever see the
race condition that it protects against, and it is the attitude that
potential errors are acceptable I find uncomfortable.

I ask again ... how does your current draft handle the race conditions
created when users do NOT have the same version of data and may well be
fed data that is out of sync with the publish3d event data? This thread
is still under the 'managing historic data' item, and being able to read
the matching version of data is the only way to achieve that, something
that could perhaps be classed as 'optional', but the distribution race
problems are VERY MUCH to do with current data and something that can be
totally eliminated using exactly the same process. If you are happy to
distribute unreliable data then that fact should be documented so that
people understand the holes.

Of cause if tzdist is 'only' to feed iCalendar services then perhaps we
need something different to distribute TZ data to services that do not
want iCalendar formats such as all of the core OS systems?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

v2.23.0 | Report a Bug | By Email