Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Re: [GSoC] Restlet integration with Equinox

Hi all,

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 starting points:

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:
http://wiki.restlet.org/developers/172-restlet/124-restlet.html

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:
http://wiki.restlet.org/developers/172-restlet/350-restlet.html

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:
http://wiki.restlet.org/docs_2.0/13-restlet/21-restlet/318-restlet/321-restlet.html

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 :)

Best regards,
Jerome

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 :
Hi Jerome,

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 agree.


I've recently created a wiki page for this project. Maybe we could
propose another GSoC project for this specific topic?

"ECF integration"
http://wiki.restlet.org/developers/172-restlet/350-restlet.html

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.

Thanks,

Scott





Back to the top