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
signature.asc
Description: This is a digitally signed message part.
