Error during command authentication.
Error - unable to initiate communication with LISTSERV (errno=111). The server is probably not started.
> 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. Hadn't spotted xsd:dateTime when I was writing the schema (or it may have been it wasn't in the version of the XML Schema or the SOAP toolkit I was using at the time...) otherwise I would have done so. > 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). Yes, there's a long standing bug on my Nokia that wo'n't sort e-mails properly (particularly annoying with e-mails from Australia which always sort to the top ;-) ) > 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. Mmmm, my view is that the server agrees to keep the result set for this time. It may keep the result set longer but shouldn't delete it before this time (apart from in exceptional circumstances e.g. a crash). > 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. <:-( I think I would argue for date/time as being less ambiguous (even if not more accurate in the real world) and allowing some future proofing in that we can layer ZiNG over transports with higher latency should the need arise, without making changes to the base spec. So we have 1 vote for xsd:dateTime and 1 vote for xsd:duration. What do the others think? Matthew