Here is my suggestion. It probably makes sense to keep two separate
classes, even though UriBuilder can potentially
be used to create any possible URI. I think it is still useful to be
able to manipulate query parameters independent
of the URI that they are to be applied to, and I think the abi
Marc,
> The builder is strictly that, a builder, so I'm not sure if it makes
sense to add read capabilities to it
Agreed. I actually don't think these two classes (UriBuilder and
UrlEncodedQueryString) overlap much. How about I propose this as a
direction:
1. JSR-311's UriBuilder plans to
On Nov 1, 2007, at 5:45 AM, Michael McMahon wrote:
I wonder if you have an opinion on the points/questions raised below?
I'd like to get agreement on the general shape of the API before
anyone goes off and reworks the existing proposal.
Some comments interspersed below.
Michael McMahon wrot
Marc & Paul,
I wonder if you have an opinion on the points/questions raised below?
I'd like to get agreement on the general shape of the API before
anyone goes off and reworks the existing proposal.
Thanks
Michael.
Michael McMahon wrote:
I agree with most of the suggestions below. The main thi
I agree with most of the suggestions below. The main things
we want are:
1) alignment, ie. the JSR311 class extends the java.net class
although I would imagine that if JSR311 is finalised before jdk7
then it will not initially extend it. So, it should at least be aligned
sufficiently so
Marc,
Thanks for your reply.
> The JSR 311 UriBuilder has methods for scheme, host, port and
userInfo. We did have authority too but removed it since its a composite
of some of the others.
Right, sorry - I missed those when I was looking at the JavaDoc.
> I think it would make sense for the
On Oct 12, 2007, at 6:31 PM, Richard Kennard wrote:
> [UriBuilder has] 4 methods associated with accessing URI
templates of a class or method, but it is simple to generalize by
removing such methods
This seems a good starting point. If I may propose a logical
progression:
1. We split J
Paul,
> [UriBuilder has] 4 methods associated with accessing URI templates of
a class or method, but it is simple to generalize by removing such methods
This seems a good starting point. If I may propose a logical progression:
1. We split JSR311's UriBuilder into a JSR311-specific version and
Paul Sandoz wrote:
Hi Richard, Michael,
Some clarifications on UriBuilder, URI templates and URI processing in
JSR-311.
UriBuilder is primarily concerned about making easy to safely and
efficiently build URIs. It was designed to be general in nature rather
than scoped to a certain way in JS
Hi Richard, Michael,
Some clarifications on UriBuilder, URI templates and URI processing in
JSR-311.
UriBuilder is primarily concerned about making easy to safely and
efficiently build URIs. It was designed to be general in nature rather
than scoped to a certain way in JSR-311. If it is at a
Michael (Paul? Marc?),
Looking at the JSR311 URIBuilder, and with respect to Mark (Reinhold)'s
concerns, I actually don't think there is much of an overlap between
them. Specifically:
1) javax.ws.rs.core.UriBuilder seems primarily concerned with building
URIs by leveraging UriTemplates
2) ja
11 matches
Mail list logo
