I never got around to answer this, back when you wrote it. I think it's
an excellent proposal. I think it would be best if it was completely
optional for clients to use it, though (they MAY use it for whatever
they wish). Just so it doesn't add any extra work for client authors. It
would still be useful (you just need to choose a good client).
/ Hampus
On 02/18/2010 04:46 PM, Peter Pöml wrote:
Hi,
so far, mtimes (modification times) of files are not specified as an element in
the Metalink format. This strikes me as odd, and it makes me remember that I
always find it lacking when downloaded files don't get the correct mtime.
(There are some clients that try to take the mtime from the Last-Modified
header, but I think that doesn't reliably work, and doesn't work with FTP at
all.)
Copying mtime is indispensable for yielding local files that can be used with
rsync without causing unneeded checksumming. (Difference in size or difference
in mtime are the criteria for rsync to trigger complete checksumming over a
file.)
Size& mtime are two pretty good criteria to quickly judge for a file's
up-to-date-ness, which is why rsync uses them.
Including the mtime in Metalinks would make it possible to reliably transmit
this piece of information.
So I propose to include an<mtime> element, similar to the existing<size>
element. It should be optional. Client software SHOULD make use of it, if the element is
present, and the operating system has support for it.
The format of the element should probably allow for subsecond (fraction) time
values, since some operating systems seems to have that.
Thoughts?
Peter
--
You received this message because you are subscribed to the Google Groups "Metalink
Discussion" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/metalink-discussion?hl=en.
