From: Jerome Louvel <jerome.louvel_at_noelios.com>
Date: Mon, 16 Apr 2007 11:10:38 +0200

Hi Stefan,

[...]

> It seems Restlet's goal is to enable building any kind of
> RESTful HTTP app. Jérome seems to see JSR 311 as a
> lightweight, high-level API on top of Restlet (as one
> possibility); from this perspective, it's OK if JSR 311 isn't
> sufficient for everything, and it's "wrong" if 311 does
> something Restlet can already do (at least that's my
> understanding). I believe making JSR 311 self-sufficient is
> preferable. I see no reason why (as has been suggested)
> Restlet classes that overlap can't be candidates to be
> "pulled into" the JSR for standardization.

This is partially true. I'm fine with the natural overlap between both the
Restlet API and the JSR API, as long as the JSR API stays focused on its
core design choice: being annotation-centric (with support
classes/interfaces as required of course).

Some classes have already been (partially) pulled into the JSR such as the
EntityTag (Tag), the NewCookie (CookieSetting), the MediaType and
Representation classes. If there is no natural or satisfactory way to
replace them with pure annotations, I don't have any particular issue with
this pulling.

I agree that JSR-311 shouldn't be dependent on another API (like Servler or
Restlet or JAX-WS or JavaMail). But it's not because their may be a
functional gap between the Servlet or JAX-WS APIs and the JSR API that the
JSR API should be extended to fill it, especially if this is not natural
with its annotation-centric design. This gap would be better filled by the
implementation code. In the case of the Restlet API, that would reduce the
overlap and ensure a cleaner mapping.

See the attached illustrations for details on my view of those functional
overlap.

> I'm not at all sure I like the RESTlet API,
> which is quite likely
> because I still haven't looked at it ihn
> detail. But I would
> definitely welcome it as one possible starting
> point for this JSR,
> just as much as the current proposal from Marc and Paul.
>
> I agree (in welcoming RESTlet as a starting point). I
> dont have any experience with it either so can't comment about it.
>
> Jerome, what is it that you feel jsr311 should do that
> Restlet doesnt (or vice-versa) and what are your reasons for
> keeping them separate?

I don't think it would makes sense to submit the Restlet API as a starting
point of this JSR unless we significantly broaden the scope of the JSR. Here
is a partial list of features that are not covered by this JSR:
 - REST component/connector model
 - client-side applications support (based on the same API)
 - advanced processing flow (filtering, routing, transformation, etc.)
 - guarding/authentication
 - advanced virtual hosting

[...]

Best regards,
Jerome