Stephan Koops wrote:
>> 3) UriInfo serves two purposes. Get access to direct information in the
>> URI, like query, matrix and path segments and get access to
>> contextual information related to the matching process, like methods
>> associated with path parameters and the ancestors. It might make
>> sense to split the interface, for example UriInfo and
>> UriMatchingInfo, which makes it easier to split the
>> implementations and for the two to evolve separately.
> Let path parameters ans path segments at UriInfo, so -1 for this detail.
>
> for the other: IMO
>
> * Access to the ancestor resource URIs belongs (also) into UriInfo.
> * Put the access to the ancester resources in an interface which
> also gives access to the ancestor resource URIs
>
> If UriInfo should be splitted, than my proposal is: create a new
> Interface Ancestors with the methods getResourceURIs(),
> getResourceURIs(boolean) and getResourcs() with the same semantic as now
> in UriInfo (including the proposal 2 above) and remove
> UriInfo.getAncestorResources(), but let both getAncestorResourceURIs(.)
> with their current semantics (inclduing proposal 2) in UriInfo.
>
I would prefer, if it is to be split, to be split along the clear
functional dividing line of non-matching and matching related
functionality. Otherwise, i would prefer it not to be split at all.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109