>From Robert Bihlmeyer <robbe at orcus.priv.at> >Of course all the million formats will be used by links on freesites. >All freenet implementations, and maybe even a number of supplemental >tools will have to support every format. The different programs may >not be able to share code (incompatible license, different programming >language), and due to the complexity of parsing they will probably all >understand slightly different sets of formats.
it's public domain, so the licensing is a non-issue. The code will be trivial to port to any language that you can get a yacc/bison for (which is at least C, perl, java and python), and not terribly hard for any language that there is at least some sort of parser-generator for. I think it's fair to call any language with no parser generator available too obscure to be useful. it's actually quite simple; a 10-element grammar, a few tables, and a little math, so I don't think there will be a lot of trouble with inconsistent implementations. It will be nowhere near the most difficult task in writing an alternative freenet implementation. >The original problem was that hex-seconds-since-1969 are difficult to >generate without computer help (not that anybody would /want/ to >generate them when not in front of a computer, but anyway). So a >scheme that translates [YYYYMMDDHHMMSS] into the appropriate >representation would seem enough. If one ignores spaces, dashes and >colons inside the brackets, friendlier representations like >[YYYY-MM-DD HH:MM:SS] are instantly possible. Just enough complexity >to make people comfortable. > >I don't recall people crying for the ability to enter [August 12] in >Freenet URLs. > >If relative dates are really wanted, the syntax could be augmented to >allow [+n] and [-n] with n being seconds. Yes, you'll need a >calculator to compute what 5 weeks worth of seconds are, but freesite >authors only need to do that once. > >-- >Robbe One of the original complaints about YYYYMMDDHHMMSS is that calendar dates are difficult to work with and support, both to usefully parse and generate... supporting them at all is much of the work, so we may as well support them in a robust fashion, and using already-available code to parse them in a consistent fashion without requiring everyone to write their own date parsing code should reduce the work required to do so. -- Benjamin Coates _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
