UriInfo stuff

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 16 Apr 2008 16:57:24 +0200


Some proposed changes to UriInfo:

1) Since we allow @Path("id") PathSegment i propose we have an
    equivalent method on UriInfo.

2) There is a problem with the ancestor related methods in that they
    return n - 1 paths and resource instances, where n is the number of
    currently matched path segments. When in a sub-locator method it
    makes it hard to get the n'th matched path. When in a constructor it
    makes it hard also, since one cannot necessarily determine if the
    whole path has been consumed. When in a HTTP method one can get the
    final path from a different method in UriInfo, but it seems
    appropriate to at least handle all information consistently.
    I propose that we rename "Ancestor" to "Matched" and return n matched
    stuff consistent for sub-locators, constructors and HTTP methods. The
    parent path or resource would aways be at index 1 in the list.

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.


| ? + ? = To question
    Paul Sandoz