On Mon, Feb 04, 2002 at 10:55:40AM -0000, Matthew Dovey wrote:
> The only change I have serious issue with (as you suspected) is the TTL
> type. I originally intended this to be a time/date stamp when the result
> set expired rather than a duration.

I had not read it that closely, my appologies. I had read the name
(time to live) saw that it was a string, and assumed "duration" from
the name. "Time to live" implies to me a duration (how long left) rather
than "expiry time" which to me implies a point in time when it dies.

I am not stressed either way, but I would use xsd:duration or xsd:dateTime
rather than string. May as well use the appropriate SOAP type for it.

> The problem with duration is when do
> you start measuring it from (the time the client sends the request, the
> time the server receives the request, the time the server sends the
> response, the time the client receives the response). With network and
> processing latency these four events will occur at different times. Have
> a date/time removes this ambiquity (we'll assume that all machines have
> decent mechanisms for keeping their clocks synchronised e.g. the NTP
> protocol). It would also allow us in the future to consider although
> transport mechanisms for SRW which have larger latencies, e.g. SOAP over
> SMTP.
>
> Matthew

I understand your arguments, but I think the assumption of clocks being
synchronized is too big in real life. I think of all those PC's out
there, including ones at people's homes etc. Then there are all the
problems of time zones etc (and the fact that software writers do
get it wrong at times).

I think time-to-live would be better as a duration, but where the value
is a hint. The server is allowed to keep the result set longer or shorter
as it deems appropriate. So clients should not rely on it. Knowing the
exact date/time (and then assuming clocks are synchronized) or duration
from "now" I suspect makes almost zero difference. The client still does
not know how long it will take for its request to get to the server again,
so while using a date/time reduces the inaccuracy, it does not eliminate
inaccuracy.

So duration has inaccuracy, date/time has smaller inaccuracy but relies
on clocks being synchronized.

Oh, more SOAP toolkits support date/time than duration by the way. <:-(

Alan