Pretorian wrote:Ayo wrote:
- How should a '/' be escaped? '\/'? That will cause any conforming client to not only ignore the MD parameter, but the entire message:
This version of the protocol reserves all other escapes for future use; any message containing unknown escapes must be discarded.
You're right, and on second thought I'd a) use a backslash as delimiter or b) not allow forward slash in names.
Both solutions are fine with me. They're actually pretty much equivalent anyway, option (a) would disallow a backslash in names.
Pretorian wrote:Ayo wrote:
- I don't really like the idea of putting another escaping mechanism within an esacping mechanism, or a protocol-within-a-protocol, depending on how you look at it. I'd prefer to use regular parameters instead, though I can understand how it is less flexible.
The problem is, as you say, the flexibility. I'd prefer to not 'waste' parameters (one for author, one for date, one for bitrate etc). I know that we have a fairly large span to use,
my preference would simply to be to confine the parameters for metadata.
With the escaping out of the way, the only further parsing required is to simply split off the name from the value. That is too trivial in any programming language to make me complain about it.
So I'm fine with the original idea.
Pretorian wrote:I see your concerns and I don't have any immediate response. Do clients want to format data in their own way? (In terms of date I can imagine to simply send the amount of (milli)seconds since the Unix epoch.) Bit-rate for audio files are commonly used with kBit/s, do anyone else e.g. use MBit/s? In any case, I'd imagine (which is why I took Explorer as an example) that most of the metadata is simply retrieved from the system. How the system define each metadata is... well, up to the system. (Do different systems define 'date' differently?)
Not sure what "system" you are refering to, but with the proper libraries a client will be able to retreive *any* file information. I can also imagine that libraries return bitrates in bit/s rather than kbit/s, but I am indeed not aware of any application that displays them in anything other than kbit/s. Also, "bit rate" is ambigious: video files have bit rates for the audio and video streams. And then there is a problem that these rates are often not even constants, in which case different applications display different rates (overall average vs. first few frames, etc...). But specifying all that may be overkill.
That aside, at least the representation of data should be specified: e.g. the string "256kbit/s" can't be interpreted by a client that only expects a number.
Pretorian wrote:More people need to chime in, methinks, on a) what metadata people could want, b) how the format of the extension should be (single or multiple parameters) and if a hard specification on each respective metadata is required.
a) Actually, I am only interested in the last modification time at this point. Zip archives, web browsers and many other applications tend to set the last modifcation date of extracted/downloaded files to the meta data it fetches from the archive/HTTP headers. I'd love to see DC clients do the same. (Yes, I realize last modification dates are not always reliable, but they can be quite useful in certain situations)
b) If you mean combining everything into a single MD parameter vs. having multiple MD parameters, then I prefer the latter since that allows easier code re-use - no need to define and implement more escaping/unescaping.
c) (hard specification): Preferably, yes. At least for a few common fields. We don't have to be very strict on less common fields, otherwise client developers may get scared away by all the specification needed in order to add new fields. >_>