Hi Piyush,
I went through the same path before converting myself to the new API
included in SVN:
handle(Call call) ==> handle(Request request, Response response)
The advantage of using Call as a holder of Request and Response is that you
indeed encapsulate more information, having a handle() method that looks
simpler at a first glance, leaving room of some properties (like
"attributes") that are neither request-related or response-related: there
are more related to the call processing itself.
Concerning the lazy creation, I don't think we could gain a lot on that
front. Either we need just a Request (like the client connectors) and we can
pass directly a Request instead of a Call, either we need both, and there is
a very high chance that the Restlets will have to set and output
representation or at least a status. I don't think this point should matter
in the decision.
The main drawback of this approach, is that you require one level of
indirection for all/most properties: call.getRequest().getInput(),
call.getResponse().setStatus(...), etc. For sure handle(Call call) is
simpler that handle(Request request, Response response) but we still have
only two parameters for a method, which is a reasonable ratio IMO. Also, all
the using code gains in clarity: request.getInput(),
response.setStatus(...), etc.
In addition, even if you can create a Request without any related Response
instance, the opposite isn't true, the Response constructor needs a related
Request and exposes it as a "request" property. So, the Response class could
act somewhat like the Call class if passing (and especially returning) only
one parameter is important.
Even though I initially liked the Call concept very much for its compacity,
I now tend to see it as an over-abstracted concept, leading to potential
ambiguity (is this property related to the request-part or to the
response-part of the call?) and overweight.
Best regards,
Jerome
> -----Message d'origine-----
> De : Piyush Purang [mailto:[EMAIL PROTECTED]
> Envoyé : lundi 9 octobre 2006 11:15
> À : [email protected]
> Objet : Re: Breaking Call into Request and Response (Was:
> Allow Header)
>
> Been thinking over the weekend on this issue. I rather like the call
> interface. It is a unified and well encapsulated entity.
>
> How about keeping the Restlets "handle(Call)" as is and let it
> extract the request and response objects as and when it requires?
>
> Call.getRequest()
> Call.getResponse()
>
> Sometimes the client code only needs either Request or Response
> objects and sometimes both. And this will also reduce parameter
> clutter while declaring new methods.
>
> Another +ve might be lazy initialization of these two objects. The
> code internally might not create these two objects till the
> first time
> their getters are called. This might lead to performance gains for
> code that just relies on one of both.
>
> Thoughts?
>
> Cheers
> Piyush
>
>
