[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[equinox-dev] Re: [GSoC] Restlet integration with Equinox
- From: Jerome Louvel <jerome.louvel@xxxxxxxxxxx>
- Date: Sun, 04 Apr 2010 12:15:50 +0200
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:188.8.131.52) Gecko/20100111 Thunderbird/3.0.1
Sorry for the late reply, I'm on vaccations... well sort of :)
Let me try to summarize the situation. It seems to me that we have two
1) The Restlet community which has expressed a recurrent need for OSGi
in order to offer a more dynamic Restlet runtime. This project was
summarized over time on this wiki page:
2) The ECF community which sees the value of Restlet as a way to
implement and support the "remote declarative OSGi services" features.
This project was summarized recently on this wiki page:
The goal of 1) is to leverage all/most features of the Restlet Framework
(Restlet API + engine + extensions) and, in addition, to leverage
OSGi/Equinox core features to bring support for dynamic Restlet
applications deployment/replacement and versionning.
The goal of 2) is to leverage all/most features of OSGi (Core +
declarative remote services) and, in addition, to leverage the Restlet
Framework to provide better REST coverage on the server-side (and maybe
on the client-side as well).
It is important to note that the Restlet API has its own containment
model, with concepts of component, connector, virtual host, application
and resource as illustrated here:
From 1) point of view, it wouldn't be acceptable for the Restlet
community to be constrained to systematically use OSGi declarative
remote services API to build their dynamic Restlet applications.
However, many users would love to leverage some core OSGi/Equinox
features to add more dynamicity to their Restlet applications -> First
GSoC project proposition.
From 2) point of view, it wouldn't be acceptable for the Equinox/ECF
community to be constrained to systematically use the Restlet API to
build or consume RESTful web services either. However, some users might
like to leverage some Restlet advanced features (like content
negotiation, conditional method processing, rich Java API mapping to
HTTP semantics, etc.) in their distributed OSGi applications -> Second
GSoc project proposition.
Regarding Jetty, it can be used with Restlet in two ways. First, as a
regular Servlet container as pointed out by Scott, or as a standalone
Restlet connector (bypassing the Servlet layers) to directly use the
Restlet layers, providing a lighter solution. Note that while Restlet
applications can be deployed into Servlet containers if needed, many
users prefer standalone deployment of Restlet applications in Restlet
components, using Restlet connectors (such as Jetty).
I hope this helped to clarified :)
PS: I've put in copy the various persons interested in this
Equinox/Restlet GSoC project(s) as I'm not sure how many follow this
list. Sorry for any duplicate email.
Le 29/03/2010 19:33, Scott Lewis a écrit :
Jerome Louvel wrote:
Hi Scott, Rajeev and all,
Thanks for your interest Rajeev in this GSoC project.
Scott, it seems that the integration of Restlet with ECF could give
you with fully-featured server-side REST support. This would also be a
nice use case for the GSoC "Restlet integration with Equinox" project.
I've recently created a wiki page for this project. Maybe we could
propose another GSoC project for this specific topic?
I think that would be a great idea. One point of
information/interest...there are already several ECF committers and
contributors that would probably also be interested in this 'second
step'...i.e. of using Restlet API on Equinox/OSGi server to implement an
ECF remote services host provider. Actually, Bryan Hunt is one such ECF
contributor, and he may be interested in this sort of use case as well.