Changing the metalink date & time format?
Anthony Bryan
in .metalinks.
I've kinda put it off, but it's of course better to deal w/ later than
much later :)
currently the spec says RFC 822, which I've been told has been
obsolete since 2001 :)
Example: Mon, 15 May 2006 00:00:01 GMT
ISO 8601 / RFC 3339 has been suggested, which looks like [YYYY]-[MM]-[DD].
Example: 2008-01-09T16:33Z
http://en.wikipedia.org/wiki/ISO_8601
I just wanted to get everyone's comments, if the generator & download
client authors agree, if they'd rather use a different format or what.
I'm guessing most download clients don't make much use of the date at
all but we'd want to test them all to make sure none choke
we'd also want to coordinate release of new generators (& possibly
download clients) if they make use of the date.
we could also possibly release a script to update (or just remove the
date completely) from old .metalinks using the old date format, if
there seem to be lots of probably.
I've added a page to the google groups wiki for this & other comments
/ proposals: http://groups.google.com/group/metalink-discussion/web/spec-comments
--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads
Nicolas
we should change it. Otherwise: "if we'll break compatibility, we may
as well go all the way", and release metalink spec 3.1 with more
changes than just date format :)
Sebastien WILLEMIJNS
> multiple people have asked about changing the date & time format used
> in .metalinks.
>
> I've kinda put it off, but it's of course better to deal w/ later than
> much later :)
>
> currently the spec says RFC 822, which I've been told has been
> obsolete since 2001 :)
> Example: Mon, 15 May 2006 00:00:01 GMT
now specs are http://rfc.dotsrc.org/rfc/rfc2822.html
let me see cut&paste below 2 specs
**************************************** BEGINNING OF RFC822
5.1. SYNTAX
date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
date = 1*2DIGIT month 2DIGIT ; day month year
; e.g. 20 Jun 82
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
time = hour zone ; ANSI and Military
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)
5.2. SEMANTICS
If included, day-of-week must be the day implied by the date
specification.
Time zone may be indicated in several ways. "UT" is Univer-
sal Time (formerly called "Greenwich Mean Time"); "GMT" is per-
mitted as a reference to Universal Time. The military standard
uses a single character for each zone. "Z" is Universal Time.
"A" indicates one hour earlier, and "M" indicates 12 hours ear-
lier; "N" is one hour later, and "Y" is 12 hours later. The
letter "J" is not used. The other remaining two forms are taken
from ANSI standard X3.51-1975. One allows explicit indication of
the amount of offset from UT; the other uses common 3-character
strings for indicating time zones in North America.
**************************************** END OF RFC822
**************************************** BEGINNING OF RFC2822
3.3. Date and Time Specification
Date and time occur in several header fields. This section specifies
the syntax for a full date and time specification. Though folding
white space is permitted throughout the date-time specification, it
is RECOMMENDED that a single space be used in each place that FWS
appears (whether it is required or optional); some older
implementations may not interpret other occurrences of folding white
space correctly.
date-time = [ day-of-week "," ] date FWS time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date = day month year
year = 4*DIGIT / obs-year
month = (FWS month-name FWS) / obs-month
month-name = "Jan" / "Feb" / "Mar" / "Apr" /
"May" / "Jun" / "Jul" / "Aug" /
"Sep" / "Oct" / "Nov" / "Dec"
day = ([FWS] 1*2DIGIT) / obs-day
time = time-of-day FWS zone
time-of-day = hour ":" minute [ ":" second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (( "+" / "-" ) 4DIGIT) / obs-zone
The day is the numeric day of the month. The year is any numeric
year 1900 or later.
The time-of-day specifies the number of hours, minutes, and
optionally seconds since midnight of the date indicated.
The date and time-of-day SHOULD express local time.
The zone specifies the offset from Coordinated Universal Time (UTC,
formerly referred to as "Greenwich Mean Time") that the date and
time-of-day represent. The "+" or "-" indicates whether the
time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
Universal Time. The first two digits indicate the number of hours
difference from Universal Time, and the last two digits indicate the
number of minutes difference from Universal Time. (Hence, +hhmm
means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
minutes). The form "+0000" SHOULD be used to indicate a time zone at
Universal Time. Though "-0000" also indicates Universal Time, it is
used to indicate that the time was generated on a system that may be
in a local time zone other than Universal Time and therefore
indicates that the date-time contains no information about the local
time zone.
A date-time specification MUST be semantically valid. That is, the
day-of-the-week (if included) MUST be the day implied by the date,
the numeric day-of-month MUST be between 1 and the number of days
allowed for the specified month (in the specified year), the
time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
number of seconds allowing for a leap second; see [STD12]), and the
zone MUST be within the range -9959 through +9959
******************************************* END OF RFC2822
> ISO 8601 / RFC 3339 has been suggested, which looks like
> [YYYY]-[MM]-[DD].
> Example: 2008-01-09T16:33Z
IMHO if new specs is enabled, old format *must* be kept for older
compatibility
ple
> I've added a page to the google groups wiki for this & other comments
> / proposals:
> http://groups.google.com/group/metalink-discussion/web/spec-comments
locked page, another guy modfies this page now ?
Rene Leonhardt
> ISO 8601 / RFC 3339 has been suggested, which looks like [YYYY]-[MM]-[DD].
> Example: 2008-01-09T16:33Z
and generates RFC 822 according to the spec.
We will add support for parsing the new date format and when the new
specification is in place, change the generation of dates to the new
format by default.
I would prefer overhauling the whole specification to make it more
compatible to XML standards and good style as already several times
requested (see James Clark's comments).
The developers should suggest and vote for the most needed changes and
features.
What about download counting and multi-file BitTorrent piece checksums
for example?
Many enterprise companies must have accurate download statistics, how
does Metalink fit into this requirement?
John Haller from portableapps.com answered to my Metalink support
questions, that he would only consider it when it gains more momentum,
i.e. a big browser would support Metalink.
Can someone get in contact with the right Mozilla person to help with
the XML parsing?
What about Opera? They already included a BitTorrent client.
And while working on these fronts, every big download manager must me
convinced and helped to support Metalink.
Nicolas
wrote:
> compatible to XML standards and good style as already several times
> requested (see James Clark's comments).
>
> the XML parsing?
> convinced and helped to support Metalink.
a lot more programs supporting metalink, and *then* change the spec
significantly. At least when we get closer to finishing a new spec, we
should temporarily suspend "evangelism". Generators creating old
format isn't such a problem. Download managers not supporting new
format is bad...
Sebastien WILLEMIJNS
> Those are conflicting goals unfortunately. It's not a good idea to get
> a lot more programs supporting metalink, and *then* change the spec
> significantly. At least when we get closer to finishing a new spec, we
> should temporarily suspend "evangelism". Generators creating old
> format isn't such a problem. Download managers not supporting new
> format is bad...
it would be great to know what changes between 3.0 and next 3.1 ?
minor update(s) ? core change(s) ?
Nicolas
wrote:
> minor update(s) ? core change(s) ?
Anthony Bryan
>
> On Jan 9, 9:09 pm, "Anthony Bryan" <anthonybr...@gmail.com> wrote:
> > ISO 8601 / RFC 3339 has been suggested, which looks like [YYYY]-[MM]-[DD].
> > Example: 2008-01-09T16:33Z
>
> The Metalink Editor (and therefore the Metalink Library, too) parses
> and generates RFC 822 according to the spec.
> We will add support for parsing the new date format and when the new
> specification is in place, change the generation of dates to the new
> format by default.
>
> I would prefer overhauling the whole specification to make it more
> compatible to XML standards and good style as already several times
> requested (see James Clark's comments).
> The developers should suggest and vote for the most needed changes and
> features.
> What about download counting and multi-file BitTorrent piece checksums
> for example?
> Many enterprise companies must have accurate download statistics, how
> does Metalink fit into this requirement?
I think suggestions & voting would be great.
torrent piece checksums, and especially download statistics (which has
been repeatedly requested) would be good improvements. does anyone
want to suggest a solution?
having a stable (minor compatible changes) & trunk (overhaul, major
new features) spec would be good.
we need some unity & simplicity though, so things aren't confusing. in
2+ yrs of progress, people are still being won over. for example,
wxDownload Fast hasn't been updated at all in almost a year. now,
that's open source so if needed it could be forked if/until the
developer had time to add support for a new version of metalink. but
even worse, closed source apps will probably be VERY slow to update if
at all, unless the new features are so compelling, easy to add, and
there's many sites & widespread use along w/ everyone clamoring for
it.
so, now we have a good foundation (the current one), but it'd be good
to be progressing towards something better as well when people are
ready for it.
> John Haller from portableapps.com answered to my Metalink support
> questions, that he would only consider it when it gains more momentum,
> i.e. a big browser would support Metalink.
> Can someone get in contact with the right Mozilla person to help with
> the XML parsing?
> What about Opera? They already included a BitTorrent client.
> And while working on these fronts, every big download manager must me
> convinced and helped to support Metalink.
I don't blame him. at least for most sites, and many types of files,
there's no compelling reason to use .metalinks because the mainstream
support from browsers like Firefox & Opera aren't there.
I've worked on contacting them myself, but I think we need to do it in
an organized group fashion. and some I've given up on :) so we need to
re-contact them.
Bram Neijt
And as you can see, I'm not voting either for or against. It is always
harder to adhere to old formats, but not impossible. In the end it
just works if we all do the same thing, and that is what the spec will
do.
I don't think much, if any, of the downloaders use the date in any
realistic or dependent manner, and I don't think changing it would be
a problem.
So, if you ask me, just change it if you feel it should be done. Here
are some possible values:
Atom specifies that dates be in the format described in RFC 3339
(which is a subset of ISO 8601).
http://en.wikipedia.org/wiki/Atom_%28standard%29
PHP supports (by default) ISO 8601 date (added in PHP 5) and RFC 2822
formatted date.
RSS uses RFC 822 http://www.rssboard.org/rss-specification
So, if you ask me, you should start a new thread and call a vote on
"what will the new date format be?":
RFC 3339
RFC 2822
RFC 822
?
Greets,
Bram
PS I'd probably vote RFC 3339, but if you think we should change, call
the vote and we will see.
Sebastien WILLEMIJNS
> I think suggestions & voting would be great.
>
> torrent piece checksums, and especially download statistics (which has
> been repeatedly requested) would be good improvements. does anyone
> want to suggest a solution?
torrent piece checksums is only interesting when software dev use
libtorrent, why copy in the metalink content the same thing is included
in the torrent ?
downloads stats is a software request, not our problem !
> having a stable (minor compatible changes) & trunk (overhaul, major
> new features) spec would be good.
backward compatibility is better ;)
Sebastien WILLEMIJNS
On Thu, 10 Jan 2008 00:36:09 +0100, "Bram Neijt" <bne...@gmail.com>
said:
> So, if you ask me, you should start a new thread and call a vote on
> "what will the new date format be?":
> RFC 3339
> RFC 2822
> RFC 822
I purpose to start the vote in a week for one week... my choice will
nomally be 822+2822 if backward compatibility or 822 in other choice...
another idea is to only ask to use GMT in date format...
Hampus Wessman
problems. No clients should rely on these dates anyway, so they should
just ignore them if they fail to parse them. Starting a new thread to
vote about which format should be used would be a good idea.
When it comes to the actual format I think the DateTime format from the
XML Schema standard would be the most logical choice. It's based on ISO
8601 and seems to be very simple, but effective. Apparently RFC 3339 is
also subset of ISO 8601. I don't know what the exact difference is.
A description of the xml schema datetime can be found here:
http://www.w3.org/TR/xmlschema-2/#dateTime-lexical-representation
A description of the RFC 3339 format can be found here:
http://tools.ietf.org/html/rfc3339#section-5.6
The only difference I can find is that RFC 3339 allows the letters ('T'
and 'Z') to be either upper or lower case.
Some examples of xml schema datetimes (and probably RFC 3339 too):
2002-10-10T12:00:00-05:00 (time zone -05:00) and the same thing in GMT
would be 2002-10-10T17:00:00Z (UTC/GMT).
The good thing about using the datetime format from the xml schema
standard would be that it would be really easy to describe the metalink
format using an xml schema (there's already a great one on the web site,
for those who haven't seen it yet). So because this is an xml standard I
think that would be the logical choice. It can be converted into other
formats if individual apps want to use something else and it doesn't
contain the names of months or something else that makes it
unnecessarily complex.
The xml schema standard says nothing about RFC 3339, even if they seem
to be nearly identical. Perhaps it would be easiest to just stick with
the xml schema standard and not mention the other, in the metalink
specs? I would probably vote for that.
Hampus Wessman
> having a stable (minor compatible changes) & trunk (overhaul, major
> new features) spec would be good.
specific right now, but an idea would be to make all versions which is
3.x compatible with each other and so on. Then it would be possible to
work on a draft for 4.0 (which would introduce non-compatible changes)
and in the mean time work on 3.1, 3.2, 3.3 and so on with smaller and
compatible changes. Could even have "Release Candidates" of the next
major version (like 4.0RC1) before it is finally released. They could be
examined by everyone on this list and posted on the web site. After one
of these RCs have been approved it would be released as the current
stable version and the work on 4.1 and 5.0 would start. The minor
versions could be released as soon as it was clear that they wouldn't
break anything. Many open source projects seem to work a bit like this.
I think it could work for an open xml standard too...
In that case I think the standard would state that clients which
supports 3.0 should accept every 3.x version. I know my editor doesn't
do that right now, which is a problem when a new version is released...
Any comments?
Nicolas
practical use does it have to change the version number?
Hampus Wessman
> Just a question... If we do changes compatible with 3.0, what
> practical use does it have to change the version number?
>
the other hand a good versioning scheme could be very practical for
developers. Otherwise you don't know when something has changed. It also
makes it possible to compile a nice changelog, listing what was changed
for each version. I think it's a good idea. It could be kept out of the
metalink file, perhaps, but I think it should be there somewhere...
Nicolas
it.
Of course we can keep version numbers on the spec. Think of HTTP.
There are lots of extensions, yet the protocol itself is still version
1.1, and it won't be changing version number anytime soon.
Hampus Wessman
That's just how I would have handled the version numbers. It can be done in many different ways. Not changing the version number, unless necessary, can be a good too. Any other suggestions?
Sebastien WILLEMIJNS
generally, when you change anything, you must change the number...
Nicolas
wrote:
parse further if version is not "3.0".
Sebastien WILLEMIJNS
On Thu, 10 Jan 2008 13:00:04 -0800 (PST), "Nicolas"
<nicolas...@gmail.com> said:
> > generally, when you change anything, you must change the number...
>
> But that would make it INcompatible. A lot of clients would refuse to
> parse further if version is not "3.0".
workaround can be to creating a new field named "revision" ;)
Hampus Wessman
Would be nice though, if clients could show the (advanced) user what version of the metalink format a file uses and perhaps a small warning, saying that it might be unable to parse parts of the file, somewhere if it's not completely supported (eg the app only knows about 3.0 - 3.2 and the file uses 3.3). What Sebastien says is the way it usually works. Ideally you should know that every file using the same version really do use the same version and not just different versions called the same.
Adding a revision number (as Sebastien suggests in another mail) and not changing the version number attribute might be a good solution. I could be included in the metalink or just kept in the docs as a help for developers to distinguish between different versions. Wouldn't interfere with the current clients, at least.
Sebastien WILLEMIJNS
On Fri, 11 Jan 2008 08:08:41 +0100, "Hampus Wessman" <h...@vox.nu> said:
> Nicolas skrev:
> Adding a revision number (as Sebastien suggests in another mail) and not
> changing the version number attribute might be a good solution.
idea of a revision permit for a programmer which has been wroten his own
core metalink
to stay compatible in all cazse
if not exist "revision number" field
then
"revision number" field = 0
endif
if revision metalink=3.0 and "revision number" => 1
then
implement new function one in core metalink
endif
if revision metalink=3.0 and "revision number" => 2
then
implement new function two in core metalink
endif
and more and more....
seba...@willemijns.com
- RFC 3339
- RFC 2822
- RFC 822
- 822 and 2822 (implementation will be decided after the vote about
subversion)
- your point of vue ? ;)
begins 17 January and finished 24 January
Hampus Wessman
DateTime", though. If that would be the winner, then we can discuss how
to describe it in the spec later. They are identical anyway (except for
maybe some minor details). Also, could someone compile a list with one
example per format? Would be great if someone did...
Sebastien WILLEMIJNS
IMHO i think whatever our choice we must delete RFC822 in the new specs
because 2 digit year, i think to my son of the son of the son of the son
in 2120
which use yet metalink in his space car ;)
**********************************************************************************************************************
so the new text vote will be
"what will the new date format be to replace RFC822 ?":
a) RFC 3339
b) Directly use RFC 2822
c) RFC 2822 and keep old compatibility with RFC 822 during X years
(implementation will be decided after the vote about subversion)
?) your point of vue ? ;)
begins 17 January 0h GMT and finished 24 January 0h GMT
elements to choose:
* examples of RFC822 sheme: 27 Aug 76 0932 PDT
* diffs between 822 and 2822:
3. Four or more digits allowed for year.
7. Specifically allow and give meaning to "-0000" time zone.
14. Free insertion of comments not allowed in date.*
15. Non-numeric time zones not allowed.*
16. Two digit years not allowed.*
17. Three digit years interpreted, but not allowed for generation.
***********************************************************************************
seba...@willemijns.com
text of vote will be "what will the new date format be?":
b) we will only use RFC 2822
c) we keep RFC 822
d) RFC 822 and 2822 (if year contains 2 digit then use RFC822 else use
RFC2822)
x) your point of vue ? ;)
begins 17 January and finished 24 January
(off topic) please purpose your sentence for the second vote about
metalink changes managing !
seba...@willemijns.com
> except that RFC 2822 is already used in Metalink
IMHO, i only want keep RFC 822 for backward compatibility, but in your
purposal
UTC/GMT is the unique timezone ?
Hampus Wessman
now. It's obsolete by now and shouldn't be used unless necessary.
Clients could continue to parse the old format for some time (no matter
what the new format will be), but I think it should be very clear in the
Metalink specification that no new Metalinks should use this obsolete
format.
Not sure what you mean about the timezones.
ISO 8601 can save dates in both UTC/GMT and in a specific timezone (like
+01:00). Would be enough with only UTC/GMT, but it includes both
possibilities. Example: "2008-01-16T12:19:00Z" (timezone = UTC),
"2008-01-16T13:19:00+01:00" (same date-time in Sweden's timezone, i.e.
UTC+1).
AFAIK ISO 8601 can handle the exact same things as RFC 2822. The
difference is that it has a simpler and IMO better syntax. It places the
most significant numbers first (logical and makes it possible to e.g.
sort them easily) and only uses numbers. Everyone who hasn't read the
summary, do so:
http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/date_and_time_format.htm
Perhaps the vote should be:
1. Use RFC 2822.
2. Switch to ISO 8601.
In both cases the clients would keep backward compatibility with RFC 822
for as long as they feel like. Most of them probably don't use the dates
anyway... Generators should only generate metalinks using the new format.
Sebastien WILLEMIJNS
On Wed, 16 Jan 2008 13:47:56 +0100, "Hampus Wessman" <h...@vox.nu> said:
> Perhaps the vote should be:
> 1. Use RFC 2822.
> 2. Switch to ISO 8601.
>
> In both cases the clients would keep backward compatibility with RFC 822
> for as long as they feel like. Most of them probably don't use the dates
> anyway... Generators should only generate metalinks using the new format.
RFC2822 is not RFC822, i do not know if backard compatibility is
included in RFC2822...
answer no:
This standard supersedes the one specified in Request For Comments (RFC)
822, "Standard for the Format of ARPA Internet Text Messages",
so you can create a "E" prupose "keep RFC822 for backward compatibility
and purpose
ISO 8601 for new mandatory sheme"
Hampus Wessman
Yes, RFC 822 has been replaced by RFC 2822 and they are not compatible
with each other. Did you read my solution to that?
I don't say that they are the same, just that either we should use RFC
2822, which has replaced the old RFC 822, or we could switch to ISO 8601
(or any other format that someone think is better). No matter which new
format we choose we could keep backward compatibility with RFC 822 for
some time (it won't be needed for ever).
It could be completely optional for the clients to keep support for RFC
822. The clients could do this if they want to or just ignore RFC 822
dates. Generators should of course use the new format when generating
new metalinks. I don't think any application actually use dates right
now, so most apps (clients and generators) wouldn't need to do
anything... Those who want to support the old format could do so, for as
long as they wish (doesn't really matter, so let everyone do as they want).
Personally, I think that backward compatibility in this case is
unnecessary. I don't know about a single application using the dates yet
and in either case it's no big loss if we can't read dates in old
metalinks. I think those who want to keep support for RFC 822 can do so,
though.
Sebastien WILLEMIJNS
On Wed, 16 Jan 2008 14:39:00 +0100, "Hampus Wessman" <h...@vox.nu> said:
> I don't say that they are the same, just that either we should use RFC
> 2822, which has replaced the old RFC 822, or we could switch to ISO 8601
> (or any other format that someone think is better). No matter which new
> format we choose we could keep backward compatibility with RFC 822 for
> some time (it won't be needed for ever).
choice "A" does not contains "RFC822" word so it means in the vote if
it is the winner than RFC822 can not been used in metalink > 3.0
so if you accept a backward compatibility, please create "E" choice
and ask "ISO 8601 with backward compatibility with RFC 2822 and
RFC822 is deleted from new specs"
in all cases, it's a pity some dev except aria2c & metalinks.sf.net
maintainers does not follow us in our actual dialogs about specs !
nobody knows actually if in her metalink developpements, parsing
RFC822 date are implemented in her metalink core grin !
> It could be completely optional for the clients to keep support for RFC
> 822.
> I don't think any application actually use dates right
> now, so most apps (clients and generators) wouldn't need to do
> anything...
it seems lot of dev wrote to anthony about dates and noone these days
explain us here
"i haven't implemented metalink in my software because RFC822 is not
good for me" :-(
we wish to know (again) opinion of every dev here which has even?/ever?
implemented
date in metalink his point of vue ;)
Hampus Wessman
> On Wed, 16 Jan 2008 14:39:00 +0100, "Hampus Wessman" <h...@vox.nu> said:
>
>
>
>> I don't say that they are the same, just that either we should use RFC
>> 2822, which has replaced the old RFC 822, or we could switch to ISO 8601
>> (or any other format that someone think is better). No matter which new
>> format we choose we could keep backward compatibility with RFC 822 for
>> some time (it won't be needed for ever).
>>
>
> choice "A" does not contains "RFC822" word so it means in the vote if
> it is the winner than RFC822 can not been used in metalink > 3.0
>
> so if you accept a backward compatibility, please create "E" choice
> and ask "ISO 8601 with backward compatibility with RFC 2822 and
> RFC822 is deleted from new specs"
>
> in all cases, it's a pity some dev except aria2c & metalinks.sf.net
> maintainers does not follow us in our actual dialogs about specs !
> nobody knows actually if in her metalink developpements, parsing
> RFC822 date are implemented in her metalink core grin !
>
>
date format (RFC 822) for improved compatibility with old metalinks and
old software has ANYTHING AT ALL to do with what new date format we
choose (except for the case where the new and old format are the same,
but I hope that won't happen here). Why would it be more or less
important to keep support for the old date format depending on which new
date format we choose? This vote is about what new date format the
Metalink format should use to represent dates and times, right?
Whether to keep support for the old format or not is an interesting
question in itself, but it does not depend on which new date format we
decide to use. IMO there is no need to keep support for the old date
format. Nothing indicates that there would be any problems if we simply
forgot about RFC 822 and never mentioned it again... Keeping backward
compatibility with RFC 2822 is quite strange. Doesn't Metalink use RFC
822 right now?
"choice "A" does not contains "RFC822" word so it means in the vote if
it is the winner than RFC822 can not been used in metalink > 3.0"
That's quite obvious. If you create a new Metalink, using the new
specification, you must of course use the new date format (whichever we
choose). Clients can still support the loading of 3.0 Metalinks, using
the old date format (ie RFC 822). The spec COULD (note the word) even
recommend clients to do that for some time. IMO that would be a waste of
time and effort, though. As said, there is no indication whatsoever that
there would be any compatibility issues by switching to a new date format.
IMO the two formats that we should vote about is 1. ISO 8601 and 2. RFC
2822 (possible 3. RFC 822, because it's the current one). Whether to
keep support for the old format (for some time) needs a discussion of
it's own (and possibly a vote of it's own)... It could be handled in
many different ways (or not at all), no matter what format we choose (as
long as we don't keep the current).
By "backward compatibility" do you mean that the new Metalink format
should use both formats (so that you can create metalinks of the new
version with either date format - whichever you like too) or that the
old format (in metalinks of the old version) should be supported for
some time to make the transition smoother? What do you mean? I mean the
latter...
Sebastien WILLEMIJNS
On Thu, 17 Jan 2008 00:18:46 +0100, "Hampus Wessman" <h...@vox.nu> said:
> By "backward compatibility" do you mean that the new Metalink format
> should use both formats (so that you can create metalinks of the new
> version with either date format - whichever you like too) or that the
> old format (in metalinks of the old version) should be supported for
> some time to make the transition smoother? What do you mean? I mean the
> latter...
so i do. keep a transition of X years... actually 4 votes for the
project
of only using your sheme with no backward compatibility ;)
Anthony Bryan
>
> I don't think much, if any, of the downloaders use the date in any
> realistic or dependent manner, and I don't think changing it would be
> a problem.
>
> So, if you ask me, just change it if you feel it should be done. Here
> are some possible values:
> Atom specifies that dates be in the format described in RFC 3339
> (which is a subset of ISO 8601).
> http://en.wikipedia.org/wiki/Atom_%28standard%29
> PHP supports (by default) ISO 8601 date (added in PHP 5) and RFC 2822
> formatted date.
>
> the vote and we will see.
as threatened, I finally got around to testing most clients & none
that I tested had problems with RFC 3339 date & time. (I should have
done that to begin w/...)
OK: aria2, DTA, GetRight, FDM, KGet, metalink checker, Net Transport,
Orbit, Retriever, SmartFTP, TheWorld, wxDownload Fast
untested: Celerius (in devel), metadl, snappy (in devel), Speed
Download (no mac on hand)
as far as I know, no developers were against this move. my proposal is
that in 2-4 weeks an updated spec (Metalink 3.0 Third Edition or
Update 3) is released, w/ new versions of generators that need to be
switched over. I'd also like to clarify any minor issues in the spec &
do any minor improvements we can.
from the list of generators: metalink tools, geo mcfly, simba/mpr,
metalink-library, metalink editor
of these, from memory metalink tools & editor don't use date/time info
so they won't need to be updated.
simba/metalink.packages.ro & metalink-library will. geo mcfly might.
we also need to update the schema & GRDDL XSLT (which I've been told
will be much simpler now).
anything I've forgotten?