Thanks Stephan,
My responses are in-line:
On Mon, May 26, 2008 at 4:03 AM, Stephan Koops <Stephan.Koops_at_web.de> wrote:
> Hi,
>
> I'm not a spec lead, but here are some personal opinions to some of your
> comments. I've inlined them.
> @All: comment or correct, if something is wrong etc.
> @Sean: If you are not a member of the mailing list
> users_at_jsr311.dev.java.net, join the list to get all answers. (see
> https://jsr311.dev.java.net/servlets/ProjectMailingListList; you must have
> an account on java.net)
>>
>> Configuration through ApplicationConfig
>> Is there any way to tighten up the getResourceClasses() and
>> getProviderClasses() to return something more specfic than sets of
>> <Class<?>>?
>>
>
> What do you mean here? Because the providers and root resource classes are
> POJOs, it's not required, that they implement any interface or subclass any
> class. Can you give a proposal?
I suppose that should have been obvious to me. Maybe because it wasn't
it might be helpful to mention why the typing is loose.
In past specification efforts, I've observed there is group knowledge,
usually in the form of assumptions or agreements, that never makes it
into the specification. The art, I suppose, is knowing when to include
that information. By this phase in the specification process I expect
the spec is pretty tight and there are good reasons for the form the
spec takes. It is also the best time to have a few outsiders come in
and see if they can spot any of the group knowledge that may not have
made it into the spec.
>> On page 5, line 23, I think it is a bad idea to depend on another spec
>> to define how something fundamental as publishing a Provider in Java
>> SE is done. That said, I am unfamiliar with JAX-WS. Personally, I
>> think Spec interdependencies are dangerous and should be avoided in
>> general. If this spec takes the position of leveraging JAX-WS then
>> there should be an up-front section explaining where and why this is
>> done.
>>
>
> In my undestanding no runtime enviroment is required to support JAX-WS. The
> implementation on top of Restlet (www.restlet.org) do also not support
> JAX-WS providers, and will throw an UnsupportedOperationException for a call
> of RuntimeDelegate.createEndpoint(..).
> IMO the full section 2.2 describe some possible default ways. Only if a
> concrete runtime enviroment should support JAX-WS, than it must support this
> way.
Does this mean there is a missing cross-reference and comment?
>> Page 10, line 13, what does "closest matching provider" mean? How is
>> closeness determined?
>>
>
> The closest in the exception class hierarchy. Sean, you are right: A link to
> section 4.5 is useful here.
>>
>> Page 10, line 30, what is the "declared metadata?" Seems like this
>> should be more clearly specified.
>>
>
> The metadata are the http headers. You are right: This is not clear in the
> full spec and also in the API. Perhaps we could rename
> Response.getMetadata() to getHeaders() and so on.
>>
>> Page 12, line 8. What would happen if @ProduceMime("text/html")
>> decorated the getWidget method. It seems like there should be an
>> error.
>>
>
> I think, you mean page 13, line 8. If there is a custom entity provider to
> convert a Widget to text/html, than it is no problem; otherwise you are
> right. But you are also right, the example is a little bit inconsistent
> according to the media types.
>>
>> Page 15, footnote. I suggest using a less esoteric wording. I have no
>> idea what an "Explicitly platonic method" is. Does it mean that I have
>> declared that I love it in a non-sexual way?
>>
>> Are there other forms of content negotiation supported other than
>> URI-based?
>>
>
> There are also the default http capabilities (headers "Accept*").
> BTW: UriInfo should change a little bit according to this, see
> https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1277
>>
>> Page 19, line 21 & 22. I would prefer that constructors with the same
>> number of parameters either not be allow or be undefined. This avoids
>> unanticipated compatibility issues.
>>
>
> IMO the spec allows a little bit undefinition here. But we could also change
> it.
I feel the way constructors are handled should not be undefined. I
think it is pretty fundamental and this is where specs tend to fall
down. Some poor soul is going to stumble across this in a year when
s/he tries to port a project to another implementation.
>> End of Chapter 5. There is a blank page.
>>
>
> All chapters start on an odd page number, so an empty page is inserted, as
> before chapter 1.
I realized that and then didn't remove my comment.
>
> best regards
> Stephan
Again, thanks Stephan. BTW, I am a big fan of Restlet! I haven't
participated lately because I now write management code (PowerPoint).
Sean