maybe this should be brought up on the IETF list, [email protected], where metalink ID stuff should be discussed. IETF people like that, whereas I almost feel like I'm intruding :)
I don't think 100 was too limiting, but maybe as more people use metalink 255 would be. I'm thinking of "640K should be enough for everybody" :) On Tue, Dec 1, 2009 at 4:08 AM, Matthias Fuchs <[email protected]> wrote: > 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 >> of (ordered) metaurls/urls to 255? This would seem like an arbitrary - >> 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; >> because if people start counting at 1 and use increments of 1, and not >> 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. >> >> Difficult matters. One should have more experience in protocol design ;) >> >> Peter >> > > > You can have an unlimited number of urls as they can have the same priority. > So there is no reason why you should always increment with 1. Additionally > there is no definition of how the relative difference is to be treated. That > is all up to the application developers. > > 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 > if locations are specified. > > Btw. for 3.0 2nd ed it was 100 to 1 so you could have started with 99. ;) > > The range 1-255 I suggested was just a number that matches a datatype > (unsigned char). > > matthias > -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads -- 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.
