Re: [Planetlab-arch] Proposed Changes for Dynamic Slice API
Brought to you by:
alklinga
Menu
▾
▴
Re: [Planetlab-arch] Proposed Changes for Dynamic Slice API
|
From: Timothy R. <tr...@in...> - 2004-01-26 21:20:52
|
At Mon, 26 Jan 2004 16:11:52 -0500 (EST), Steve Muir <sm...@CS...> wrote: > in what sense is it harder to debug? since the functions for manipulating > epoch-relative values are all part of the standard C library i would > expect them to be well debugged already. and why is this well-defined > value less portable than some string for which we have to point people to > a complex spec. for example, do you know how many spaces go between the > month and date strings if the date string is only a single digit? I think the argument Aaron's making is similar to the reason that 'Date:' headers in HTTP and RFC2822 are textual rather than numeric - it does make things much easier, even though the explicit assumption in these standards is that the values will be hidden by a web browser or MHA. It does make a difference. Yes, there will be programmers who get their regexps wrong, but it'll be easier for them to debug. I speak from experience, having written a bunch of date parsing functions, and it would have been more painful without a set of human-readable input datasets. Parsing rfc2822 dates now is sufficiently widespread that everyone will just use the relevant library functions. Actually, there's even a somewhat cheeky argument that something that is (a) hard to parse, and (b) supported by library functions in all common programming languages, is better than a format that is more likely to tempt programmers to write their own (buggy) parser... Either way, I'm not terribly religious about this. I hope this won't develop into a flame ware... -- Mothy > yes, there will be programmer error when 123.456 gets interpreted as 456 > microsecs, but there will also be a ton of programmers who get their > regexps wrong when, say, the date or hour is a single digit. > > i'm assuming that there will always be a program between the output of the > API and the end user (isn't that why it's called the programmatic API?), > so i'd rather make it easy for the program to parse the input and use > existing functions to output a value in whatever the format the user > wants. if you have to output anything other than UTC values you're going > to be converting to an internal epoch-relative value anyway. > > steve > > > > On Mon, 26 Jan 2004, Aaron Klingaman wrote: > > > You may be right about that, but my instinct tells me not to use a > timestamp > > like that. Harder to debug, a bit less portable than a generic string. > It'll > > cost a bit more to parse and ensure the timestamp is correct, but I think > > it'd be worth it in the long run. > > > > Aaron > > > > On Monday 26 January 2004 03:47 pm, Steve Muir wrote: > > > i don't think it makes using the API any more difficult on non-UNIX > boxes. > > > python, and i imagine perl and most other scripting languages, can > > > manipulate epoch-relative values directly, as can any C program (the > ctime > > > function and its relatives are part of C89). or am i missing something? > > > > > > steve > > > > > > On Mon, 26 Jan 2004, Aaron Klingaman wrote: > > > > How much more difficult will it make using the api on non-linux type > > > > machines, like a windows box? > > > > > > > > I would vote for a more readable string. > > > > > > > > ak > > > > > > > > On Monday 26 January 2004 03:35 pm, Steve Muir wrote: > > > > > yes, i meant exactly what you wrote. i wrote 'UTC epoch' since i > > > > > wasn't sure if the definition of Unix epoch specified that it was > > > > > relative to UTC. > > > > > > > > > > we could presumably support sub-second resolution using floating > point > > > > > numbers (or fixed point if there are accuracy issues with floating > > > > > point), but i haven't thought through whether that has complications. > > > > > > > > > > i agree that this makes it less straightforward to check timestamps > > > > > visually, but on the other hand i expect that it will eliminate a > bunch > > > > > of parsing errors; parsing an integer/float is much more 'uniform' > than > > > > > parsing a string like "Mon Jan 26 15:32:46 UTC 2004" in the sense > that > > > > > i don't have to deal with special cases like single-digit values. > > > > > > > > > > steve > > > > > > > > > > On Mon, 26 Jan 2004, Timothy Roscoe wrote: > > > > > > At Mon, 26 Jan 2004 15:06:18 -0500 (EST), Steve Muir > > > > > > > > <sm...@CS...> wrote: > > > > > > > how about seconds since UTC epoch? it's easiest to parse and > meets > > > > > > > all of your requirements. > > > > > > > > > > > > > > steve > > > > > > > > > > > > I don't think there is a UTC epoch. But I'm assuming you mean the > > > > > > Unix epoch, which is "seconds since 00:00:00 UTC, January 1, 1970". > > > > > > That works for me too, but is harder to debug. > > > > > > > > > > > > -- Mothy > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > > > Premiere Conference on Open Tools Development and Integration > > > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > > > http://www.eclipsecon.org/osdn > > > > > > _______________________________________________ > > > > > > Planetlab-arch mailing list > > > > > > Pla...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/planetlab-arch > > > > > > > > > > ------------------------------------------------------- > > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > > Premiere Conference on Open Tools Development and Integration > > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > > http://www.eclipsecon.org/osdn > > > > > _______________________________________________ > > > > > Planetlab-arch mailing list > > > > > Pla...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/planetlab-arch > > > > > > ------------------------------------------------------- > > > The SF.Net email is sponsored by EclipseCon 2004 > > > Premiere Conference on Open Tools Development and Integration > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > http://www.eclipsecon.org/osdn > > > _______________________________________________ > > > Planetlab-arch mailing list > > > Pla...@li... > > > https://lists.sourceforge.net/lists/listinfo/planetlab-arch > > > > > |
