Re: Metalink and xsd:integer

[Peter Pöml]

Hi Matthias,

Am 01.12.2009 um 10:08 schrieb Matthias Fuchs:

Am Montag 30 November 2009 23:54:11 schrieb Peter Pöml:

Am 29.11.2009 um 22:25 schrieb Anthony Bryan:

so, you proposed a range of 1 to 255...

any objections or other suggestions? :)

Regarding metaurl and url, doesn't this effectively limit the number

and needless- restriction to me. There should be no reason why the
specification should forbid 1000 urls that are all ordered, which
could be a valid use case, for whatever reason. I agree that the spec
should be definite, but it shouldn't put up restrictions that are not
needed I think. If limiting the numbers, I'd suggest a reasonably
large range that matches a commonly used datatype, like a short int
(16-bit) or an int (32-bit), which would leave ample room (one would
think).

However, the spec doesn't give any guidance yet about the use case of
the priorities. The use case we have in mind is that we start with 1
(highest priority) (where we started with 99 in the past and counted
in the opposite direction), and then increment the value, right? That
could be made explicit (although there doesn't need to be a
requirement about fixed increments either). Anyway, the relative
difference of the priorities is what matters. Maybe an alternative to
defining a fixed a range could be to describe a suggested usage;

10 or 100 (which they might happen to do), the chances of hitting
funny limits would be much higher.

Even _if_ specifying a range, it might be useful to suggest the
following: a client that can process datatypes only of a certain size
might ignore those entries that come with a higher (larger number)
priority than whatever their implementation choses to being unable to
process. Does this make sense? Or am I crazy? :-)

Altogether, I think it would be useful if the spec suggests to start
counting at 1, increment in steps of 1, _in_order_to_ decrease the
chances that any potential client might run into a limit. A client
should support at least priorities to 255 (absolute minimum), but
better one byte more ;-)

Well, it's just my opinion.



Peter

of (ordered) metaurls/urls to 255? This would seem like an arbitrary - because if people start counting at 1 and use increments of 1, and not Difficult matters. One should have more experience in protocol design ;)

You can have an unlimited number of urls as they can have the same priority.

Yes - that's why I wrote "ordered". Maybe it wasn't clear enough, sorry: I was referring *only* to the number of URLs with differing priority, not to the number of URLs with identical priority, the latter is obviously not limited by the range.

So there is no reason why you should always increment with 1.

Surely I wouldn't want to see a limit of 255 priorities.

I'm not sure how you meant that - if you say, there's no reason to always increment at all, I have to say that I have to in most cases, if I want to create an ordered list within a country. (And there are also quite many countries.) There's a practical use case that I have in mind, it's not made up or academical - I certainly hope that the number of openSUSE mirrors grows by a factor of 2 or more in the coming years, although I don't know if it will happen. If you rather meant "no reason why you should use increments as small as 1", then I'd counter that a small range of 1-255 would be a very good reason to prefer small increments over larger ones... ;-) It's not that I don't like the idea of the definition as such, and the binding & clarity that it brings, it's just that I would either make it bigger or be less limiting.

Additionally

is all up to the application developers.


if locations are specified.



The range 1-255 I suggested was just a number that matches a datatype
(unsigned char).

matthias

there is no definition of how the relative difference is to be treated. That What you should also keep in mind is that locations can be defined. In case you have 10 urls with the same priority you could still rank them more finely Btw. for 3.0 2nd ed it was 100 to 1 so you could have started with 99. ;)

Thanks for discussing this interesting point!
Peter

smime.p7s
Description: S/MIME cryptographic signature