On Apr 12, 2007, at 10:30 PM, Dhanji R. Prasanna wrote:
>
> On 4/13/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
> E.g. currently HttpRequestContext has methods associated with a
> request and HttpResponseContext has methods associated with a
> response. Would merging those two classes into one make really things
> simpler ?
>
> I think before we start talking about which approach is simpler, we
> should try and decide what is really NEEDED, and this should be
> driven by specific usage scenarios. We can model everything in HTTP
> just because it exists (whether we expose it as one or many
> artifacts), but I dont think that will serve the API well.
>
I agree.
> For one thing, I have not yet heard a concrete use case as to why
> we need an HttpRequestContext in addition to the metadata injection
> via method parameters.
I agree that most things in there could be injected as method
parameters but to do so separately would require 10 new annotations
(assuming all the request data obtainable remains desirable). Perhaps
we should consider a somewhat coarser granularity, e.g. we could have
an injectable UriInfo interface that contains the HttpRequestContext
methods associated with the request URI rather than injecting each
part of the information separately.
HttRequestContext is also used by the WebResource interface to pass
request data to non-annotation capable application code like JVM-
based scripting languages or JavaME classes. Given the unpopularity
of WebResource so far this use case could disappear.
I think the precondition evaluation methods remain useful for
singleton resource classes but for per request resource classes we
could adopt an annotated method approach for obtaining the necessary
metadata instead.
> Or why Representation<T> doesnt encapsulate metadata returned in
> the response. Is this the 20/80 facilitator? If so I'd worry about
> later.
>
I don't understand that comment, Representation<T> does encapsulate
metadata returned in the response: content type, content language,
content location, last modified and etag.
> Similarly for HttpResponse and its subclasses. Each subclass is an
> abstraction for a certain kind of response like a temporary redirect.
>
> These subclasses should definitely not be exposed to an app
> directly. Afaia concerned these are implementations of specific
> usage scenarios--not generic programming interfaces. If you want to
> provide a utility, then it should be as a static factory (similar
> to j.u.Collections as Ive said elsewhere), otherwise there really
> will be a class explosion (what happens when new types of response
> abstractions are introduced?)
>
> Imagine if we had a public class for each of the utility Executors
> in j.u.c!
I take your point, so far we'd only run into a few responses that
seemed to deserve their own subclass and an application could always
extend the base Response class or one of its subclasses should it
need something else. A factory pattern would also work.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s