Re: XML mapper for GWT

[Rob Heittman]

This is really fantastic, Harald!  We're undergoing a major update of two of
our GXT and Restlet powered projects, and I suspect this is just what the
doctor ordered.  If r6416 fixed my cookie bug (and I think it did, thanks
Thierry) I can move on to having a look at this.  I'm super excited!

- Rob

On Fri, Mar 26, 2010 at 9:02 AM, Harald Pehl wrote:

> Hi Jerome,
>
> I'm pleased to announce Piriti 0.3.1. Piriti now supports mapping both JSON
> and XML data. Here are some of the features:
>- Built-in support for many types (primitives, String, Date, Enums, ..)
>- Possibility to specify date and number formats
>- Support for mapping arrays and collections
>- Flexible XML mapping using XPath expressions
>- GXT extension for mapping to GXT models
>- Restlet extension built on top of the Restlet GWT edition
>
> For the Restlet extension I implemented two representations:
>- PiritiJsonRepresentation which extends JsonRepresentation
>- PiritiXmlRepresentation which extends DomRepresentation
> They use Piriti readers to map the incoming JSON value / XML document to
> POJO(s).
>
> Resources:
>- Project page: http://code.google.com/p/piriti/
>- Getting started: http://code.google.com/p/piriti/wiki/GettingStarted
>- Restlet extension:
> http://code.google.com/p/piriti/wiki/RestletExtension
>- Sample application: http://piriti-sample.appspot.com/
>
>
> Have fun,
> Harald
>
> http://haraldpehl.blogspot.com/
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2465437
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2465689

Multiple cookie bug (2.0RC1 and snapshot)

[Rob Heittman]

Hi all,

I haven't explored it in sufficient detail yet to have a patch, but
request.getCookies() is returning only the first cookie sent by the browser,
I think since some of the engine refactoring in early March may have to do
with it?  I think it was OK before then.

A quick step thru seems to indicate that CookieReader gets the first pair,
caches the second pair, but never gets visited again to actually read pairs
2..n

- Rob

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2465032

Re: Grizzly or Jetty?

[Rob Heittman]

My $0.02 ... Grizzly has some advantages over Jetty, but the connector is
less well-exercised.  I choose Jetty for its stability balanced with very
good performance.  Load Impact was not able to measure any consistent
external differences between a Restlet site hosted on both connectors,
although over the local network I could observe a slight performance boost
by using Grizzly.

I have high hopes for the new Restlet M7 internal connector to actually
become the fastest and most scalable Restlet delivery solution -- initial
benchmarks are promising -- but it's still a baby, even more so than the
Grizzly connector.

On Mon, Feb 1, 2010 at 3:41 PM, Sopasakis Pantelis wrote:

> Hi all,
>  Maybe the question "Grizzly or Jetty" is hard to answer but I'd like
> your opinion on that. I'm developing a web service that runs as a
> standalone application using Grizzly. I'm wandering if there is a
> difference in performance between these two connectors or if there is
> some other even more efficient solution.
>
> Thank you in advance,
> Pantelis Sopasakis
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2443962
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2443965

Re: GWT RPC servlet next to the gwt RESTLET

[Rob Heittman]

Exactly, although we seem to have a difference of opinion here as to how
best to do it.  We're going to tackle this issue on Refactor Friday.

On Mon, Feb 1, 2010 at 10:51 AM, Tim Peierls  wrote:

> On Mon, Feb 1, 2010 at 10:16 AM, Rob Heittman 
> wrote:
>
>> Well, GwtShellServlet itself is only useful in versions of GWT (1.6) that
>> use Tomcat in hosted mode.  Beyond that (2.0...  I never really used 1.7)
>> Development Mode is tightly coupled to Jetty.  We lose The ability to mount
>> Restlet at root as GwtShellServlet does.  Ordinary ServerServlet works fine
>> here.  Once your GWT app is compiled, of course it doesn't matter what the
>> server side is.
>>
>
> Ah ... and this is what you were hoping to write up? How to route things
> differently depending on whether you're in dev mode?
>
> --tim
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2443841

Re: GWT RPC servlet next to the gwt RESTLET

[Rob Heittman]

Well, GwtShellServlet itself is only useful in versions of GWT (1.6)  
that use Tomcat in hosted mode.  Beyond that (2.0...  I never really  
used 1.7) Development Mode is tightly coupled to Jetty.  We lose The  
ability to mount Restlet at root as GwtShellServlet does.  Ordinary  
ServerServlet works fine here.  Once your GWT app is compiled, of  
course it doesn't matter what the server side is.

I've been waiting on Google to open source the Google Eclipse Plugin,  
which they hadn't last I checked-- it would be easy to add some  
settings to this to bootstrap a new GWT app for Restlet.  As it  
stands, it's sheer hell keeping all the permutations and incantations  
straight.

On Feb 1, 2010, at 9:38 AM, Tim Peierls  wrote:

> On Mon, Feb 1, 2010 at 8:42 AM, Rob Heittman  > wrote:
> There is not, presently, a way to run Servlets under Restlet instead  
> of vice versa.
>
> Rob,
>
> What about re-writing (only) GwtShellServlet from the ground up as a  
> Restlet Application? Wouldn't that help those of us who don't want  
> to have the extra servlet layer (who don't want GWT RPC)? Is it just  
> too hard to do?
>
> --tim

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2443817

Re: GWT RPC servlet next to the gwt RESTLET

[Rob Heittman]

There is not, presently, a way to run Servlets under Restlet instead of vice
versa.  There are some RFEs to cover this:

"Request and Response wrapper for Servlet API"
http://restlet.tigris.org/issues/show_bug.cgi?id=512

(and peripherally, but useful to probably the same class of problems)

"Support JSP representations"
http://restlet.tigris.org/issues/show_bug.cgi?id=753

With M7's beefed up internal HTTP connector, I am becoming an even better
fan of this idea of having a primarily Restlet server that can run a Servlet
every now and then when it has to.

If anybody wants to attack RFE 512, most of the necessary tricks are in
here:

http://gogoego.googlecode.com/svn/trunk/modules/org.gogoego.rack/src/org/gogoego/rack/

this Rack connector for Restlet has to convert Restlet concepts to Servlet
concepts so that jruby-rack can work under a pure Restlet container.  It
works fine in production, but is neither elegant enough for inclusion in
Restlet nor flexible enough to handle Servlets in general.

This was written against 1.2M5 or so; may not work against M7 directly.

- R

On Mon, Feb 1, 2010 at 6:21 AM, Xavier Méhaut  wrote:

> Hello,
> I wonder how to mix in the same application serverside RPC servlet and
> calls to restlets, ie I have a GWT GUI which calls either a GWT RPC service
> or a remote restlet... The only I found up to now, is to run the application
> in a Servlet container by usisng the servlet connector... but I would prefer
> launching a RESTLET application which could manage both cases described
> above.
> regards
> Xavier
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2443784

M7: httpclient OSGi dependencies

[Rob Heittman]

Think it would be possible to have the bundled org.apache.httpclient have a
manifest dependency on the bundled org.apache.httpcore and
org.apache.commons.logging packages?  I had to introduce these myself to get
things started.

It's pretty cool to be serving things up out of the Restlet native
connector!

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2443378

Re: RIAP protocol and "local" Representions

[Rob Heittman]

We use a lot of RIAP but very little ConverterService ... that might change
if it worked more like you expect out of the box.

On Mon, Jan 25, 2010 at 2:17 PM, Valdis Rigdon wrote:

> Is no one else using RIAP in this
> way? Or are people using RIAP and letting objects be serialized
> locally?

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2441755

Re: handlePropfind() not being called when PROPFIND request is received (to add WebDAV support to a ServerResource)

[Rob Heittman]

Is the workpsaces/workspaces typo below significant?

On Jan 16, 2010, at 9:39 AM, Fabian Mandelbaum   
wrote:

> Hum... one more thing I've found out while testing, I've removed
> OPTIONS support from the RootFolderResource (serving the / URI) and
> now the error is different:
>
> [fab...@laptop ~]$ cadaver http://localhost:9000/workpsaces/W1/content
> Could not open collection:
> 405 The method specified in the request is not allowed for the
> resource identified by the request URI
> dav:/workpsaces/W1/content/? quit
> [fab...@laptop ~]$
>
> So, I'm wondering... maybe the problem is that all 'intermediate'
> resources should implement at least the OPTIONS method too in order
> for the 'deeper' resource to work?
>
> Thanks again...
>
> 2010/1/16 Fabián Mandelbaum :
>> Thanks Rob (and sorry for miswritting your lastname ;)).
>>
>> For all it's worth I've just tried with cadaver (DAV command line
>> client), and got the same results, CLI 'session' and excerpt from the
>> logs follow:
>>
>> [fab...@laptop ~]$ cadaver http://localhost:9000/workpsaces/W1/ 
>> content
>> Could not access /workpsaces/W1/content/ (not WebDAV-enabled?):
>> 405 The method specified in the request is not allowed for the
>> resource identified by the request URI
>> Connection to `localhost' closed.
>> dav:!> quit
>> [fab...@laptop ~]$
>>
>> Jan 16, 2010 12:06:26 PM com.calenco.resource.RootFolderResource  
>> options
>> INFO: OPTIONS request processed in 0.000 sec.
>> Jan 16, 2010 12:06:26 PM org.restlet.engine.log.LogFilter afterHandle
>> INFO: 2010-01-1612:06:260:0:0:0:0:0:0:1 -
>> -   9000OPTIONS /workpsaces/W1/content/ -   200  
>> 0   -   8   http://localhost:9000   cadaver/0.23.2
>> neon/0.29.0 -
>> Jan 16, 2010 12:06:26 PM org.restlet.engine.http.HttpServerAdapter  
>> commit
>> WARNING: A response with an unavailable entity was returned. Ignoring
>> the entity for resource
>> "http://localhost:9000/workpsaces/W1/content/";.
>> Jan 16, 2010 12:06:26 PM org.restlet.engine.log.LogFilter afterHandle
>> INFO: 2010-01-1612:06:260:0:0:0:0:0:0:1 -
>> -   9000PROPFIND/workpsaces/W1/content/ -
>> 405 402 288 7   http://localhost:9000   cadaver/ 
>> 0.23.2
>> neon/0.29.0 -
>>
>> Thanks in advance
>>
>> On Sat, Jan 16, 2010 at 11:00 AM, Rob Heittman
>>  wrote:
>>> I ran into similar trouble porting it myself, but that was many
>>> milestones ago ... Will retry with M6 and see if I get the same
>>> results as you!
>>>
>>> On Jan 16, 2010, at 8:17 AM, Fabian Mandelbaum >> >
>>> wrote:
>>>
>>>> Hello there, I'm trying (fighting and learning, bah ;)) to add  
>>>> WebDAV
>>>> support to a ServerResource. To test, I'm using the Nautilus/GNOME
>>>> "Connect to Server" WebDAV client. I've seen that 1st an OPTIONS
>>>> (HTTP) request is issued, then a PROPFIND (DAV) request is issued.
>>>>
>>>> My resource has options() overriden and it's being called properly;
>>>> however, there's no propfind() method in ServerResource, so reading
>>>> the docs a bit I've found that to implement handlers for 'new'  
>>>> methods
>>>> (or for not-yet-handled-by-any-out-of-the-box-handler method),  
>>>> simply
>>>> a handleMethodName() is needed, so I've added handlePropfind() to  
>>>> my
>>>> resource, like this:
>>>>
>>>> public Representation handlePropfind() throws ResourceException {
>>>>   return new StringRepresentation("PROPFIND called!");
>>>> }
>>>>
>>>> And I'm seeing this on the logs (together with the error message of
>>>> the DAV client stating "the method is not supported by the  
>>>> requested
>>>> resource URI", without saying *which* method is not supported,  
>>>> but I
>>>> know it's PROPFIND, from the logs):
>>>>
>>>> Jan 16, 2010 11:08:31 AM org.restlet.engine.log.LogFilter  
>>>> afterHandle
>>>> INFO: 2010-01-1611:08:310:0:0:0:0:0:0:1--9000
>>>> OPTIONS/workspaces/W1/content-2000-207
>>>> http://localhost:9000
>>>> gvfs/1.4.3-
>>>> Jan 16, 

Re: handlePropfind() not being called when PROPFIND request is received (to add WebDAV support to a ServerResource)

[Rob Heittman]

I ran into similar trouble porting it myself, but that was many  
milestones ago ... Will retry with M6 and see if I get the same  
results as you!

On Jan 16, 2010, at 8:17 AM, Fabian Mandelbaum   
wrote:

> Hello there, I'm trying (fighting and learning, bah ;)) to add WebDAV
> support to a ServerResource. To test, I'm using the Nautilus/GNOME
> "Connect to Server" WebDAV client. I've seen that 1st an OPTIONS
> (HTTP) request is issued, then a PROPFIND (DAV) request is issued.
>
> My resource has options() overriden and it's being called properly;
> however, there's no propfind() method in ServerResource, so reading
> the docs a bit I've found that to implement handlers for 'new' methods
> (or for not-yet-handled-by-any-out-of-the-box-handler method), simply
> a handleMethodName() is needed, so I've added handlePropfind() to my
> resource, like this:
>
> public Representation handlePropfind() throws ResourceException {
>   return new StringRepresentation("PROPFIND called!");
> }
>
> And I'm seeing this on the logs (together with the error message of
> the DAV client stating "the method is not supported by the requested
> resource URI", without saying *which* method is not supported, but I
> know it's PROPFIND, from the logs):
>
> Jan 16, 2010 11:08:31 AM org.restlet.engine.log.LogFilter afterHandle
> INFO: 2010-01-1611:08:310:0:0:0:0:0:0:1--9000 
> OPTIONS/workspaces/W1/content-2000-207
> http://localhost:9000 
> gvfs/1.4.3-
> Jan 16, 2010 11:08:31 AM org.restlet.engine.http.HttpServerAdapter  
> commit
> WARNING: A response with an unavailable entity was returned. Ignoring
> the entity for resource "http://localhost:9000/workspaces/W1/content";.
> Jan 16, 2010 11:08:31 AM org.restlet.engine.log.LogFilter afterHandle
> INFO: 2010-01-1611:08:310:0:0:0:0:0:0:1--9000 
> PROPFIND/workspaces/W1/content-405402124 
> 14http://localhost:9000gvfs/1.4.3-
> Jan 16, 2010 11:08:31 AM org.restlet.engine.log.LogFilter afterHandle
>
> So, the OPTIONS request is succeeding, but the PROPFIND one is not,
> even if there is a handlePropfind() in the resource.
>
> Restlet 2.0M6 here, and my work on DAV support is being based on Rob
> Heitman's Dav1VFSResource class, which seems to be the only
> 'documented' stuff about how DAV clients work.
>
> Thanks in advance for your help
>
> -- 
> Fabián Mandelbaum
> IS Engineer
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2437628

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2437629

Re: Restlet 2.0 & GWT 2.0 Dev Mode

[Rob Heittman]

I use Eclipse and OSGi manifests, so the Restlet bundles are open in my IDE
and declared as dependencies of my GWT project -- I need org.restlet and
org.restlet.ext.servlet.  But however you get the jars onto the classpath
will be fine -- I'll document a few other choices when I write this up
officially.  Then in the war directory of my GWT project, I place a
WEB-INF/lib/web.xml with contents like this:





adapter
org.restlet.ext.servlet.ServerServlet
 
  org.restlet.application
  org.restlet.Application [or your actual
Application]


  org.restlet.component
  [my component here]


 
adapter
/r/*





On Fri, Jan 1, 2010 at 12:16 PM, Bryan Hunt  wrote:

> Rob,
>
> How are you registering the ServerServlet with the embedded Jetty that GWT
> is launching?
>
> Bryan
>
> On Jan 1, 2010, at 9:18 AM, Rob Heittman wrote:
>
> We should write some now that GWT 2.0 is not a moving target any more.
>  When working with Jetty and Dev Mode under 2.0 trunk, I have always just
> used the ServerServlet to attach Restlet to a path.  I do not believe it is
> really possible any more to attach Restlet to the root of the container (/),
> at least not without surgery to GWT's DefaultServlet, which in turn is a
> modified version of Jetty's that understands how to handle GWT modules ...
> and I hope we don't have to attack that.
>
> All I do in practice, in my GWT 2.0 client applications, is make sure the
> root of any RESTful resources is configurable, and set it differently in Dev
> Mode than in production.  Then I usually attach Restlet (usually a
> redirector to my "real" Restlet server side running somewhere else) to /r
> under GWT using ServerServlet, same as any other JEE container.
>
> If that practice sounds sane to everybody else, I'll write it up.
>
> On Fri, Jan 1, 2010 at 9:56 AM, Bryan Hunt  wrote:
>
>> I'm starting to look at using Restlet 2.0 with GWT 2.0.  The docs for
>> setting up a project:
>>
>>
>> http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet/186-restlet.html
>>
>> talk about setting up the old GWT Hosted Mode.  The new Dev Mode seems to
>> be using Jetty instead of Tomcat, and there doesn't seem to be any web.xml
>> files for configuring the shell servlet.  Are there any new docs on how to
>> set up a project using Restlet 2.0 with GWT 2.0 Dev Mode?
>>
>> Bryan
>>
>> --
>>
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2434081
>>
>
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2434095

Re: Restlet 2.0 & GWT 2.0 Dev Mode

[Rob Heittman]

We should write some now that GWT 2.0 is not a moving target any more.  When
working with Jetty and Dev Mode under 2.0 trunk, I have always just used the
ServerServlet to attach Restlet to a path.  I do not believe it is really
possible any more to attach Restlet to the root of the container (/), at
least not without surgery to GWT's DefaultServlet, which in turn is a
modified version of Jetty's that understands how to handle GWT modules ...
and I hope we don't have to attack that.

All I do in practice, in my GWT 2.0 client applications, is make sure the
root of any RESTful resources is configurable, and set it differently in Dev
Mode than in production.  Then I usually attach Restlet (usually a
redirector to my "real" Restlet server side running somewhere else) to /r
under GWT using ServerServlet, same as any other JEE container.

If that practice sounds sane to everybody else, I'll write it up.

On Fri, Jan 1, 2010 at 9:56 AM, Bryan Hunt  wrote:

> I'm starting to look at using Restlet 2.0 with GWT 2.0.  The docs for
> setting up a project:
>
>
> http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet/186-restlet.html
>
> talk about setting up the old GWT Hosted Mode.  The new Dev Mode seems to
> be using Jetty instead of Tomcat, and there doesn't seem to be any web.xml
> files for configuring the shell servlet.  Are there any new docs on how to
> set up a project using Restlet 2.0 with GWT 2.0 Dev Mode?
>
> Bryan
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2434081
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2434082

Re: adding new router attachements dynamically?

[Rob Heittman]

Sometimes I end up doing just that, but unless SomeResource.class is only
handling a trivial set of cases, eventually SomeResource.class starts
re-creating all the intelligence of Router and Route, which is not very
efficient.

Following the ideas in this post, we're writing up a little something that
allows Restlet 2.0 routes to be plugged via an OSGi service.  Currently our
OSGi-based GoGoEgo container allows something like this for mounting entire
Applications, so this just takes it down to a more fine grained level.

Should be available for playing with as soon as people get back from the
holidays.

- Rob

On Sun, Dec 27, 2009 at 12:36 PM, Sopasakis Pantelis wrote:

> I'm not sure I understood the problem, but a reasonable solution would
> be the following line:
>
> router.attach("/{identifier}", SomeResource.class);
>
> then inside your resource class you can handle these identifiers.
>
> On Mon, 2009-12-28 at 11:49 +0100, Jerome Louvel wrote:
> > FYI, I’ve added a reference to Brian’s post on this page:
> >
> >
> >
> > “OSGi integration”
> >
> > http://wiki.restlet.org/developers/172-restlet/124-restlet.html
> >
> >
> >
> > Best regards,
> > Jerome Louvel
> > --
> > Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> > Noelios Technologies ~ Co-founder ~ http://www.noelios.com
> >
> >
> >
> >
> >
> >
> >
> >
> > De :xavier.meh...@gmail.com [mailto:xavier.meh...@gmail.com] De la
> > part de Xavier Méhaut
> > Envoyé : lundi 7 décembre 2009 09:12
> > À : discuss@restlet.tigris.org
> > Objet : Re: adding new router attachements dynamically?
> >
> >
> >
> >
> > I'm eager to read you soon.
> > regards
> > Xavier
> >
> > 2009/12/7 Bryan Hunt 
> >
> > Yes, there is a way to do this, but I can't go into the details.  I
> > know that's not the answer you were looking for.  A colleague and I
> > are working on a solution that allows you to register a representation
> > as an Eclipse extension or through an OSGi service.  The mechanism
> > will be dynamic and fully support the hot-plug nature of OSGi.  If you
> > are interested in the details on my first (failed) attempt at this,
> > please see my blog post (it also explains why I can't directly answer
> > your question):
> >
> >
> http://bryanhunt.wordpress.com/2009/11/23/updating-ensemble-for-restlet-2-0-license-beware/
> >
> > Once we have a working solution, I'll post another blog entry.
> >
> > Bryan
> >
> >
> > On Dec 6, 2009, at 2:41 PM, Xavier Méhaut wrote:
> >
> > > Hello,
> > > In a certain manner related to osgi, is there a means in Restlets to
> > add dynamically new attachements to ane exiting router, ie add new URL
> > to be taken into account without having either to recopile the code,
> > or (better) without having to restart the process?
> > >
> > > for instance, we had first :
> > > myrouter.attach("/toto",...);
> > > myrouter.attach("/toto",...);
> > >
> > > and I would like to add :
> > > myrouter.attach("rere",...)
> > >
> > > regards
> > > Xavier
> >
> >
> > --
> >
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2427706
> >
> >
> >
> >
> >
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2433414
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2433467

Re: Redirection?

[Rob Heittman]

RFC 2616  :-)  http://www.ietf.org/rfc/rfc2616.txt  (2626 is the Y2K RFC)

Sopasakis -- as HTTP itself doesn't have a means of specifying a delay
before a redirect, you won't get consistent behavior across every HTTP
compliant client or library.  Most user-agents will act immediately on an
HTTP redirect status code (3xx) and ignore the entity, but supplying an HTML
entity with the meta refresh tag may have the desired effect for some
user-agents.

The usual convention is to enclose a short HTML entity with a 3xx redirect,
something like this:

Moved
Please click this link if you are not automatically redirected to: ${new-location}
window.location.href="$[new-location}";


You can doctor up some variants of this using the meta refresh or Javascript
timeouts, but I suspect getting consistent behavior across basic HTTP
clients like curl and regular browsers like Firefox will be a challenge,
since you're operating at the HTML/JS level and not really the HTTP level.
 If you find a great solution, please post it back!

- Rob

On Mon, Dec 28, 2009 at 1:42 PM, Matt Kennedy  wrote:

> If you want this to be an official HTTP redirect, for example a 301, 302,
> 303, 307 status code, then you can set that status code in the response
> object and set the entity to be some html that will do your refresh to the
> new URL, plus the countdown.  Be careful if you choose to go with 301 or 302
> as the response code, read IETF RFC 2626 for details.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2433464

Re: When to use POST??

[Rob Heittman]

I agree.  I think that when the discussion starts to turn around which  
HTTP verbs map best to the idiosyncracies of relational databases  
(like safe transactional ID assignment for rows) it is a hint to try  
mapping REST onto the application at a higher abstraction level.  REST  
styles often work more naturally for high level object constructs,  
which also tend to have corresponding real-world unique identifiers.   
As the abstraction level gets higher, I find it both improves the fit  
to representational concepts, and raises the likelihood of having a  
way of deterministically arriving at URIs specific to the real world  
problem domain.

The most successful and widely adopted REST APIs seem to me to use  
natural semantic concepts, URIs included.

If the application just involves using Restlet as an implementation  
detail of a private client/server system in a controlled environment,  
then I would not fret too much about verb choice and other details as  
long as it makes sense to the implementer and maintainers, and works  
well in practice.

On Dec 25, 2009, at 9:07 PM, Niclas Hedhman  wrote:

>
> Huh? It is for the container to hand each client a different ID. I  
> think you have the assumptions that IDs must be in unbroken numbered  
> sequence. Seldom is that a requirement.
>
> -- Niclas
>
>> On 24 Dec 2009 18:57, "Ben R Vesco"  wrote:
>>
>> The client using a GET request to find an id to use for a PUT would
>> have all the problems of non-atomic operations (since it can't
>> possibly be atomic). What if two clients both call GET at the same
>> time to get the *next* id to insert? What if N clients call GET to  
>> get
>> the next id to insert but never do the PUT? PUT to a specific id is
>> really only truly useful when the id is deterministic.
>> On Tue, Dec 22, 2009 at 8:33 PM, Niclas Hedhman  
>>  wrote: > On Wed, Dec 23, 2009...
>>
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2432842
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2433228

Re: When to use POST??

[Rob Heittman]

Just a comment on this behavior by Rails ... I don't have the relevant
citations immediately at hand, but I have seen comments by DHH and others
that describe this long-standing design feature as pragmatic.  I think one
of the key drivers was that the PUT verb has historically been very
inconvenient to use by many clients, including simple Web forms.

The vocabulary of HTTP 1.1 is actually quite rich, but many frameworks elide
all but the basics, which mean that many REST designs are more spartan than
they have to be.  Using POST because PUT is simply unavailable is something
I have seen and even been forced to do myself many times.

One of the things I like about using Restlet both as a client and a server
is that it gives me nicely abstracted access to the entire conceptual
framework of HTTP.

- Rob

On Tue, Dec 22, 2009 at 10:18 AM, Conor Moran wrote:

> I found an interview with Jerome on infoQ recently which states it is best
> to use PUT for both Create & Update
>
> --- http://www.infoq.com/articles/restlet-louvel-interview ---
> InfoQ: Can you elaborate a little on your criticism of Rails in this
> regard? What's unnatural about its CRUD mapping in your opinion?
>
> JL: Beside the GET and DELETE HTTP methods that map nicely to SQL SELECT
> and DELETE verbs, I find the usage by Rails of POST method for creation
> rather unfortunate. The best method for creation in REST is PUT which is
> also used for updates. The advantage of PUT over POST is that if the
> operation fails it can be safely repeated which isn't the case for POST.
>
> Also, ...
> ---
>
> Should I ever use POST?
> If so, can you give an example of what to use this for?
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2432335
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2432348

Re: Dynamic OSGi representations

[Rob Heittman]

Sure, our crowd can clean-room implement.  I imagine either Carl Scott or I
would be the right person.  Email me details or post on the list to steer us
wide of the license minefield.

On Mon, Dec 21, 2009 at 1:30 PM, Bryan Hunt  wrote:

> Would there be any interest in a Restlet extension that would allow you to
> dynamically register representations in an OSGi environment?  This feature
> could be expanded to support representations defined by an Eclipse extension
> point.
>
> There is already code available that does this for Restlet 1.x, and I have
> code that does this for Restlet 2.0, but as I mentioned in my blog (
> http://bryanhunt.wordpress.com) there's a problem with the license, and my
> code is "tainted" by knowledge of the original source.  I was hoping that a
> colleague of mine would re-create the work I did for Restlet 2.0, but he
> doesn't appear to have the time.
>
> If anyone is interested in working on this, I can help to a certain degree.
>  If you are comfortable with the Reslet architecture, and OSGi bundles, this
> should only take a few hours to get completed.
>
> Bryan
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2432064
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2432306

Re: General question about managing screen-flow in restful browser based application

[Rob Heittman]

It is much easier to be a purist about REST when working with a fairly
capable client (e.g. GWT, Flex, handcoded JS with AJAX patterns, various
AJAX frameworks ...) that is capable of maintaining application state.

Much of the MVC plumbing of various frameworks boils down to effective
techniques for work-shifting; having the server do presentation and
application state storage work on behalf of the client.  This is one of
those cases where people have created very beautiful solutions that, at
their foundation, canonize an antipattern: the assumption that the client
suffers from acute limitations in its ability to persist application state.
 While this is still necessarily true in certain use cases (e.g. the classic
"shopping cart" example), many modern non-trivial Web applications don't
have this restriction, because they can bring a lot more power to bear.

In most of the applications we develop, the client is responsible for its
own layout altogether, and has its own MVC patterns.  We generally avoid
doing the MVC lifting on the server, because it doesn't scale as well as
pushing this responsibility onto the client altogether.  Can't always do
that, but we try!

On Mon, Dec 14, 2009 at 9:44 AM, Conor Moran wrote:

> Hi,
> this may not be the best place to post this question, but pointers
> elsewhere may be satisfactory answers.
>
> I'm struggling with the following:
> Here's the context -
>  - I'm running a web app in a browser.
>  - I was on a list of users, and I clicked an add button
>  - I get shown a form to enter some fields.
>  - I click submit
>
> So I'm about to create a new user for example:
> --
> POST /users 
> --
>
> After creating the user, in a typical web app I might expect to go back to
> the "list of users" screen. And in an MVC (Model2), the controller would
> usually handle that.
>
> The question is simple: how to handle that in a restlet app - following the
> post, go back to the user list - where does that responsibility lie?
> In general, what are the recommendations of the resty guys for doing screen
> flow - does that all move to the client side?
>
> Most of my "rest" experience comes from dealing with ruby on rails, which I
> guess is not quite purist rest. So they have a controller.
>
> My other question relates to a rails thing also.
>
> Edit screen vs. View/Show screen
> So I want to show details of a user I use:
> GET /users/{id}
>
> But they have, what seems like a hack, for getting an edit form:
> GET /users/{id}/edit
> (I'm not sure what corresponding Merb urls are)
>
> To me we are talking about one resource here, with different
> representaions. But not at the level of MediaType.
> The media type for  my web-app might be text/html for both the view and
> edit page.
>
> So again how best to handle this from the point of view of a rest purist?
>
> Any info greatfully appreciated. Perhaps I'm not looking at things in the
> right way yet.
>
> cheers
> Conor
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430295
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430340

Re: restlet server on the client ;)

[Rob Heittman]

I was thinking the same about web sockets.  We have several applications
that use Restlet in GWT to talk to a server, and I have been trying to think
about good ways to port these for offline/local use to use HTML5 database
APIs.  This might be a road in the future.  I agree, a bit iconoclastic, but
I do see use cases.

On Thu, Dec 10, 2009 at 9:38 AM, Xavier Méhaut wrote:

> It seems nevertheless that HTML5 will implement the websocket API, which
> could be used to perform such an action...
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2429210

Re: Differences between Servlet and Restlet

[Rob Heittman]

Some more info ... Not necessarily Chrome but Chrome OS X preview ...  
It attempts first to open the PDF in a broken internal browser.  Then  
because the download ticket is a one time thing, you can't re-download  
in a non broken way.  Making the ticket work a few times or for a few  
minutes would help.



On Nov 2, 2009, at 6:13 AM, Jerome Louvel   
wrote:

> Hi Rob,
>
>
>
> Another excellent reply!
>
>
>
> Regarding the issue with the green paper and Chrome, I have just  
> reported it to Manning. BTW, the book should be entering their MEAP  
> this week!
>
>
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
>
>
>
>
>
>
> De : Rob Heittman [mailto:rob.heitt...@solertium.com]
> Envoyé : vendredi 30 octobre 2009 16:08
> À : discuss@restlet.tigris.org
> Objet : Re: Differences between Servlet and Restlet
>
>
>
> Part 1 - Why web services and/or REST?
>
>
>
> I think the seminal work on this subject is still the Richardson and  
> Ruby book (which also covers Restlet), RESTful Web Services, 
> http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260
>
>
>
> There's a Manning book coming out about Restlet soon, Restlet in  
> Action.  If you don't mind surrendering your email address you can  
> get a teaser here: http://www.manning.com/free/green_louvel.html   
> (Hey Jerome, tell Manning their process doesn't work with Chrome ...  
> I only got 1 page)
>
>
>
> I personally prefer a style of application design in which you first  
> create a semantic API that solves the functional aspects of your  
> problem, then expose user interfaces or additional convenience APIs  
> so that people or programs can take advantage of it.  This is not  
> the only design process choice, but has always worked best for me.   
> If you are making web applications and want to try this design  
> process, web services are not an extra value-add feature, but an  
> intrinsic element of the process.
>
>
>
> Part 2 - Servlet vs Restlet
>
>
>
> Servlet is intentionally very simple, and provides a minimum set of  
> capabilities for writing Web-connected server side code generally in  
> a standardized way -- somewhat on the same level as CGI, FastCGI,  
> Ruby Rack, Python WSGI.
>
>
>
> Restlet is a richer API for the specific purpose of building RESTful  
> web services and aims to model the higher level concepts of the  
> Web's RESTful architecture.  To write a RESTful web application  
> using only Servlet:
>
>
>
>  - A lot of code needs to be created to properly handle complex  
> things like conditional GETs or content negotiation.  So many  
> Servlet developers just don't.  Restlet's ServerResource model  
> handles these nicely with minimal hints needed from the developer.
>
>  - To set headers, etc., you need to know the proper strings to use  
> and the nuances of their formatting.  This can be frustrating, add  
> bloat, and be hard to test.  Restlet provides a lot of classes that  
> correctly model the concepts used in HTTP.  If the usage is wrong,  
> it probably won't compile.
>
>  - It's usual REST practice to take advantage of hierarchical URI  
> space to map server side resources.  With Servlet alone, it's  
> necessary to make some sort of routing scaffold to find and execute  
> the correct target.  Restlet provides a nice routing mechanism.
>
>
>
> Of course there are other frameworks and applications you might be  
> using that would give you some or all of these advantages.  Restlet  
> is very lightweight at its core and very focused on its task.  So it  
> is easy to introduce Restlet into just about any environment  
> (embedded, JEE, Swing, OSGi ...) to simplify the creation of RESTful  
> server services and improve their correctness.  This is why I like  
> it; my team and I can write portable web service code and have it  
> work in lots of different environments.
>
>
>
> I suspect, based on list traffic, that the predominant means of  
> using Restlet is not *instead of* Servlet but in *addition to* it.   
> Folks use Restlet running on GAE or any of the horde of JEE app  
> servers, to wrap RESTful services.
>
>
>
> For those of us iconoclasts who don't need any Servlet API at all,  
> Restlet can talk directly to the low level services of Jetty,  
> Simple, Netty (new shiny thing), and other Java HTTP servers, to  
> take advantage of their specific optimizations and skip some extra  
> translation on every request.
>
>
>
> Look

Re: Differences between Servlet and Restlet

[Rob Heittman]

Part 1 - Why web services and/or REST?

I think the seminal work on this subject is still the Richardson and Ruby
book (which also covers Restlet), RESTful Web Services,
http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260

There's a Manning book coming out about Restlet soon, Restlet in Action.  If
you don't mind surrendering your email address you can get a teaser here:
http://www.manning.com/free/green_louvel.html  (Hey Jerome, tell Manning
their process doesn't work with Chrome ... I only got 1 page)

I personally prefer a style of application design in which you first create
a semantic API that solves the functional aspects of your problem, then
expose user interfaces or additional convenience APIs so that people or
programs can take advantage of it.  This is not the only design process
choice, but has always worked best for me.  If you are making web
applications and want to try this design process, web services are not an
extra value-add feature, but an intrinsic element of the process.

Part 2 - Servlet vs Restlet

Servlet is intentionally very simple, and provides a minimum set of
capabilities for writing Web-connected server side code generally in a
standardized way -- somewhat on the same level as CGI, FastCGI, Ruby Rack,
Python WSGI.

Restlet is a richer API for the specific purpose of building RESTful web
services and aims to model the higher level concepts of the Web's RESTful
architecture.  To write a RESTful web application using only Servlet:

 - A lot of code needs to be created to properly handle complex things like
conditional GETs or content negotiation.  So many Servlet developers just
don't.  Restlet's ServerResource model handles these nicely with minimal
hints needed from the developer.
 - To set headers, etc., you need to know the proper strings to use and the
nuances of their formatting.  This can be frustrating, add bloat, and be
hard to test.  Restlet provides a lot of classes that correctly model the
concepts used in HTTP.  If the usage is wrong, it probably won't compile.
 - It's usual REST practice to take advantage of hierarchical URI space to
map server side resources.  With Servlet alone, it's necessary to make some
sort of routing scaffold to find and execute the correct target.  Restlet
provides a nice routing mechanism.

Of course there are other frameworks and applications you might be using
that would give you some or all of these advantages.  Restlet is very
lightweight at its core and very focused on its task.  So it is easy to
introduce Restlet into just about any environment (embedded, JEE, Swing,
OSGi ...) to simplify the creation of RESTful server services and improve
their correctness.  This is why I like it; my team and I can write portable
web service code and have it work in lots of different environments.

I suspect, based on list traffic, that the predominant means of using
Restlet is not *instead of* Servlet but in *addition to* it.  Folks use
Restlet running on GAE or any of the horde of JEE app servers, to wrap
RESTful services.

For those of us iconoclasts who don't need any Servlet API at all, Restlet
can talk directly to the low level services of Jetty, Simple, Netty (new
shiny thing), and other Java HTTP servers, to take advantage of their
specific optimizations and skip some extra translation on every request.

Looking at it one way, Restlet slows things down and adds complexity to
Servlet.  Looking at it another way (the way I *do* look at it), Restlet
models a lot of stuff I need to model anyway in every application, and does
it in a very well tested way, backed by a crowd of smart and diligent
engineers.  This makes my web services much more responsive, efficient, and
bug-free than they would be if I created all that myself, or if I coerced a
non-REST-oriented framework into service.

- R

On Fri, Oct 30, 2009 at 10:10 AM, Dan Drillich  wrote:

> Good Day,
>
> We have here an internal conversation about the subject. Therefore, what
> are
> the benefits of using Web Services and in particular Restlets instead of
> Servlets?
>
> Regards,
> Dan
>
> --
> View this message in context:
> http://n2.nabble.com/Differences-between-Servlet-and-Restlet-tp3919100p3919100.html
> Sent from the Restlet Discuss mailing list archive at Nabble.com.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2413005
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2413025

Re: Problem with Reloading

[Rob Heittman]

Did you try it to see if you get the same behavior using a connector other
than Grizzly?  (e.g. Jetty or the included HTTP connector)  On refresh, most
Mozilla based browsers will try a conditional GET first to see if the
resource has changed, then if the server indicates that it has changed, will
repeat with the full GET.  The weird behavior you describe is also found
when running under Tomcat 5 if you don't send a large enough entity from
Restlet ... where that first conditional GET will fail and cause the same
symptoms in the browser.  So I'm wondering if it's connector-specific here,
too.

On Thu, Oct 22, 2009 at 8:38 AM, Sopasakis Pantelis wrote:

> Dear List,
>  Hi for the first time, cause I'm a new member. I've developed a web
> service based on Restlet 1.1.5 which runs as a standalone application
> using Grizzly. I deciided to migrate to Restlet version 2.0. m3 and
> after some refactoring and changes in my code, I managed to make the
> whole thing work just fine!
>
> In the server class, I attach both an application and some static html
> files including a javadoc directory. This is the server class:
>
>
> ***
>
> package org.opentox.server;
>
> import java.util.logging.Level;
> import java.util.logging.Logger;
> import org.opentox.Applications.OpenToxApplication;
> import org.opentox.Resources.AbstractResource;
> import org.restlet.Application;
> import org.restlet.Component;
> import org.restlet.data.LocalReference;
> import org.restlet.data.Protocol;
> import org.restlet.resource.Directory;
> import org.restlet.routing.VirtualHost;
>
> /**
> *
> * @author chung
> */
> public class Server {
>
>public static void main(String[] args){
>// Create a component
>   Component component = new Component();
>
>   component.getServers().add(Protocol.HTTP, 3000);
>
>   component.getClients().add(Protocol.FILE);
>
>
>   LocalReference javadoc =
>LocalReference.createFileReference(
>  AbstractResource.javadocDir);
>
>   LocalReference home =
>   LocalReference.createFileReference(
>  AbstractResource.HTMLDir);
>
>
>   Directory javadocDirectory = new
> Directory(component.getContext().createChildContext(), javadoc);
>   Directory homeDirectory = new
> Directory(component.getContext().createChildContext(), home);
>
>
>   Application application = new OpenToxApplication();
>
>   VirtualHost host = new VirtualHost();
>
>   host.attach("/OpenToxServices",application);
>   host.attach("",homeDirectory);
>   host.attach("/OpenToxServices/javadoc", javadocDirectory);
>
>
>
>   component.setDefaultHost(host);
>try {
>component.start();
>} catch (Exception ex) {
>Logger.getLogger(Server.class.getName()).log(Level.SEVERE,
> null, ex);
>}
>
>}
>
> }
> 
>
> The problem is that when I reload any of the resources that corresponds
> to a static HTML file (e.g. the javadoc), I get a status code 405
> (Method Not allowed). If I reload the page again, I get the HTML but
> without the CSS. I reload it again to get the correct HTML
> representation but without the Images contained in it. Another reload
> gives once again a status 405, then HTML without css and finally the
> correct HTML. This happens each time I press F5 on mozilla BUT NOT if I
> request the resource again, i.e. if I retype the URL. Note that this
> happens only with the static html files. Other resources that are based
> on java classes (MyResource extends ServerResource) don't have such
> problems!
>
> Having no idea how to solve that, I just separated the static files from
> the service. I set up an apache server on another port (80) to deploy
> the static html files and the services run on 3000. However I think
> other people are experiencing the same problem, because I had the same
> problem on 2 different machines.
>
> I would appreciate any suggestions or ideas on that.
>
> You can find the source code of the application at
> http://github.com/sopasakis/yaqp
>
> Thank you in advance,
> Sopasakis Pantelis
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2410202
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2410217

Re: Re: Re: Problems when registering a simple Restlet resource under OSGi

[Rob Heittman]

If the problem recurs with 2.0M5 or a recent trunk snapshot, let me know and
I'll download Pax Runner / Felix to look again.
I've seen the "socket is not connected" thing when I use the internal HTTP
connector and certain browsers; it's not actually harmful, just annoying.
 The internal HTTP connector is really only for test/demo/super-light
purposes -- best to choose any of the excellent server connectors available.
 I have been using Jetty happily for years, but have been impressed by a
first look at the new Netty connector that was just contributed.  But let's
get to the root of your environment problem first, as choosing extensions
can also be fun, different, and exciting under OSGi.

On Tue, Oct 20, 2009 at 12:29 PM, Vlatko Davidovski
wrote:

> Thanks for checking it out Rob.
> Unfortunately did not work for me, and I again get the following:
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2409757

Re: Re: Problems when registering a simple Restlet resource under OSGi

[Rob Heittman]

I don't have a working Felix handy, so I cut and pasted the Application and
Resource into a working project under Equinox, and glued the RestletService
start() method into my Equinox Application's start().
It works both starting the Application with a monolithic classloader and
also under OSGi, after I made a little change to the ServerResource so that
it could properly map the exposed variant.  I'm using a snapshot from a
couple days after 2.0M4.

public class HelloWorldResource extends ServerResource {

@Get("html")
public Representation doGet() {
StringRepresentation representation = new StringRepresentation("Hello
world!", MediaType.TEXT_HTML);

return representation;
}
}

On Tue, Oct 20, 2009 at 10:18 AM, Vlatko Davidovski
wrote:

> Rob,
>
> Thanks for checking out this problem.
>
> Yes there might be some class loading issue.
>
> Please look at the attachments for the HelloWorld example. This example
> uses iPojo, but any other OSGi technique could be used.
>
> Regards,
> Vlatko

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2409434

Re: Problems when registering a simple Restlet resource under OSGi

[Rob Heittman]

Hi, Vlatko --
I assume the issue -- as almost always under OSGi -- is one of classloader
visibility somehow.  I haven't had any problems exactly like this, but *I'm
not using ServerResource* in OSGi actively yet (still the deprecated
Resource from 1.1, as we have lots of code to port).  The problem might be
there -- I can imagine some possible visibility issues.

It would be nice to work from your simple test case ... can you share the
Hello World example?

- R

On Mon, Oct 19, 2009 at 10:21 PM, Vlatko Davidovski
wrote:

> I have problems in registering even a simple resource under OSGi and get
> the following warning:
> WARNING: A response with a 200 (Ok) status should have an entity. Make sure
> that resource "http://localhost:8080/alias/hello"; returns one or sets the
> status to 204 (No content).
>
> Any ideas why this could be happening in OSGi? In a regular Java app,
> everything works fine though.
>
> Here is the content of the simple resource I try to attach:
>
> public class HelloWorldResource extends ServerResource {
>@Get("text/html")
>public String doget() {
>
>return "Hello world";
>}
> }
>
> Thanks!
> Vlatko
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2409200
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2409390

Re: Re: Netty extension

[Rob Heittman]

This looks really exciting, Gabriel!  I haven't had a chance to try it yet
... just got back from a long and busy trip and am trying to clear my desk.
Quick question -- does the Netty connector only handle HTTP or does it also
handle HTTPS?

On Wed, Sep 23, 2009 at 2:48 AM, Gabriel Ciuloaica wrote:

> Hi John,
>
> I have used Apache MINA in one of the project that I'm working for about 5
> months. I'm talking here about a file server. The server is providing a REST
> API for other services to use for storing/retrieving files.
>
> Moved the implementation in first phase to Netty, give us performance
> improvements.
> Adding Restlet on top of Netty give us a simple way to provide same REST
> API with plugable authentication.
>
> We are in a alpha phase with new implementation but till now we did not
> encounter issues with Netty.
>
> There are some numbers regarding performance on Netty site:
> http://jboss.org/netty/performance.html
>
> Br,
> Gabi
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2398738
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2398837

Re: GET and POST - Semantics vs. Function

[Rob Heittman]

Quick pragmatic security note on this:

I actually disagree with this statement. Using GET to pass login
> parameters is fine, and in some cases preferable (particularly as it
> relates to client caching). If you're concerned about security, you
> should encrypt such requests using SSL (you really should do this
> regardless of the method used in this case).
>

Most web servers include the full URL of each request in their server logs.
These logs are not always automatically treated with the privacy accorded to
the password database.  This is one reason that many prefer to send such
data via POST, since entity bodies are not typically recorded except in
debugging situations.

- Rob

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394694

Re: ServerResource

[Rob Heittman]

In addition to Jerome's very good feedback ... since Resource/ServerResource
should be ephemeral and lightweight, they can use Scala's Actor concurrency
model to safely talk to long-lived, heavier weight domain objects if
needed.  I found this really elegant in practice, since Actors are so easy
to reason about.  I found extending Restlet to have a bit more friction with
Scala because you need to use or at least be very aware of
synchronization-style concurrency.  Something just looks mighty funny about
writing synchronized{} blocks in Scala.

One other comment -- I *think* extending ServerResource directly in Scala
presently has a few gotchas due to annotation differences between Java and
Scala; I haven't dug into these much yet as we're still extending the
original style Resource from Restlet 1.1 in production, but I remember some
test ports of Java ServerResources to Scala didn't do exactly what we
expected.  I can dig up more detail on that if it matters to your evaluation
-- and it may not be true any more; we last checked around Restlet 2.0M3 and
many issues have been fixed since then.

- Rob

On Wed, Aug 26, 2009 at 4:34 PM,  wrote:

> I'm evaluating Restlet for my next project and would like clarification on
> some design desicions.
>
> ServerResource is the preferred way to expose resources in Restlet, but is
> there a penalty to creating a new instance for each request?
>
> We will be using Scala and most of the code will follow an
> immutable/functional style.
>
> What are the downsides of just extending the Restlet class for handling
> requests?
>
> Thanks
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2387717
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2388207

Request for collaborators: Restlet-GWT Eclipse Plugin

[Rob Heittman]

Hi all,

The Google Eclipse plug-in has become -- since 1.6/1.7 and now moving on
into 2.0 -- the de facto way to spawn a new GWT application for many
people.  For reasons that should be obvious, the Google Eclipse plugin makes
it very easy to create an RPC-based GWT app that talks to Google App
Engine.  All of the plumbing -- including JDO-to-BigTable via DataNucleus
magic -- is done for you.

Unfortunately, the style of app auto-plumbed by the Google Eclipse plug-in
is not very friendly to the use of GWT with Restlet and arbitrary (non
Google, not tightly coupled) server side applications.  In some sidebar
discussions with Googlers, I have gotten the impression that the Google
Eclipse plug-in will not diverge from this pattern any time soon; it is,
after all, funded as a vehicle to encourage adoption of the entire Google
ecosystem.

I plan to have my folks dash off an alternative plugin that makes it equally
easy to create GWT plugins for any REST styled server.  This would set up a
Restlet-based proxy to your choice of server back ends, and plumb the
application with your choice of GWT core JSON, XML, and/or Restlet-GWT 2.0
clients.  I already have much of the code for this in the form of utility
scripts we use to get our work done at the office.

If anybody else working in GWT with REST sees utility to this, feel free to
post here or email me directly -- would be happy to get you involved at
whatever level you feel comfortable with.  Conversely, if you already are
down the path to such a plugin and I can just throw our existing bits into
your mix, that would be great too.

I'm aiming for this to release at the same time as Restlet 2.0 final to
better encourage REST adoption in the GWT community.  This isn't an official
Restlet thing yet -- Jerome and I haven't even discussed it yet, as we've
both been stupid busy in our respective corners -- but it would be neat if
it could someday be one.

- R

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2387395

Re: Re: OSGi vs. Service Provider patterns

[Rob Heittman]

You kept me very busy reading all the citations, but I do now agree that the
OSGi edition approach would have a multiplicative effect on the number of
editions ... I think your action plan is a good one.
On Sat, Aug 22, 2009 at 10:26 AM, Jerome Louvel
wrote:

> The action plan I propose is:
>  1) Leverage Dave's bundle fragment approach
>  2) Provide a way to refresh the helper lists via "META-INF/services"
> inspection
>  3) Add an OSGi extension to expose Restlet applications as OSGi services.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2387273

Re: Upload a zero byte file

[Rob Heittman]

I re-read the thread and I thought the only conclusion was that the spec is
inconclusive  :-)
It would probably be better for Restlet just to warn instead of error here.
 Other frameworks also refuse a no-entity PUT (sorry -- no current list, but
empirical past evidence) but I don't see a concrete reason that Restlet
should be the enforcer of this particular interpretation.  Unless there is a
technical reason why supporting a no-entity PUT is a challenge.

- R

On Tue, Aug 25, 2009 at 12:40 PM, Brian Demers wrote:

> I have a web app that accepts uploaded files.  We are using Restlet 1.1.3.
>
> If I try to upload a file with 0 bytes I get an error message: "Missing
> request entity"
>
> http://www.mail-archive.com/discuss@restlet.tigris.org/msg03579.html
>
> I don't agree with the conclusion here.  Uploading a 0 byte file should be
> acceptable, and in some cases needed for applications.
>
> When thinking about a PUT containing a message (json, xml, ect) then a PUT
> should not be empty, I could agree with that.  In the case of file upload,
> it represents the entity being empty, not missing.
>
>
> --
> View this message in context:
> http://n2.nabble.com/Upload-a-zero-byte-file-tp3511268p3511268.html
> Sent from the Restlet Discuss mailing list archive at Nabble.com.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2387222
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2387224

Re: Experience with resin application server and RESTlet?

[Rob Heittman]

I've used it with the Servlet extension, and didn't have any problems.  This
was not very recent experience (1.1 and a fairly old Resin) but it did work
just fine, the app is still in production as far as I know.  At my last
company we had a relationship with Caucho and embedded Resin in our product;
it was always very solid.

On Thu, Aug 20, 2009 at 9:12 AM, Tobias Girschick <
tobias.girsch...@in.tum.de> wrote:

> has anyone some experience with using restlets in combination with the
> resin application server (available at: http://www.caucho.com/ )? I'm
> thinking of using it and wanted to make sure if there are known
> issues/problems so that I don't waste my time...
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385614

Re: riap://host and attachDefault

[Rob Heittman]

Awesome -- I didn't know if doing so would have side effects.

On Thu, Aug 20, 2009 at 6:49 AM, Jerome Louvel wrote:

> I’ve just fixed this bug in SVN trunk and 1.1 branch. The Router class
> defines the createRoute() method, so it was easy to fix in
> Router#attachDefault() directly.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385605

Re: OSGi vs. Service Provider patterns

[Rob Heittman]

The trouble with getting caught up on mail is that everybody just piles on,
once they see you're responding  ;-)

On Mon, Aug 17, 2009 at 1:18 PM, David Fogel  wrote:

> Hi all-
>
> Jerome, any chance you'd like to weigh in with your current plans for
> resolving OSGi deployment strategy for Restlet 2.0?
>
> -Dave Fogel
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2384450
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2384454

Re: CPU at 100%

[Rob Heittman]

Yes.  Sun JDK 6U9 and above on Ubuntu Jaunty have not demonstrated any real
showstoppers for my purposes.  My highest traffic server (a Rackspace
dedicated box) handles about 15 requests per second continuously, so while
we're not pressing up against the theoretical maximums here, I feel pretty
happy that the JDK platform is stable anyway.  We haven't seen any
unpleasantness on Slicehost or Amazon EC2, the other two hosting providers
we use.  EC2/Jaunty/Sun is where we put all our new applications.  We use
the "alestic" EC2 images as a Ubuntu baseline and then prepare our own AMIs.

Unrelated, since you're also a scripting guy ... those high load servers
still need an occasional JVM restart to clear memory leaks associated with
script engine use.  I can't officially blame Rhino, Jython, or JRuby for
this, as the real culprit is almost certainly antipatterns in user-authored
scripts, but definitely the sites that run lots of scripts do leak memory
over time.  That's the only stability problem that forces occasional
restarts on our Restlet 1.2M2 based platform.

Currently I'm benchmarking stuff on 2.0M4 (well, technically a snapshot from
2 days later that fixes a Mac bug) and the performance seems better,
stability just as good.

- R

On Wed, Aug 12, 2009 at 3:03 PM, Tal Liron wrote:

> This is a very useful thread!
>
> So, when you listed the problems with OpenJDK6 on Hardy and Jaunty, does
> this mean you didn't see the same problems using Sun's JDK6 on those
> platforms?
>
> -Tal
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382994

Re: CPU at 100%

[Rob Heittman]

We use OpenJDK for dev a lot, but can't yet use it in production.  We see
the following issues:

- OpenJDK 6 with the Hotspot JIT (Hardy): dropped large I/O connections --
e.g. big file uploads.  100% CPU issues (NIO for directly for sure, also
image resizing and others, may be NIO related)
- OpenJDK 6 with the Cacao JIT (Jaunty): dropped large I/O connections.
Occasional JVM crashes (not consistently reproducible).  100% CPU issues
with NIO.  Occasional in-memory data corruption.

I don't think OpenJDK 6 works very hard at tracking all Sun bugfixes.  It
seems the bugfixes get tracked/fixed in OpenJDK 7.  But I can't use OpenJDK
7 in production for other reasons (my Java libraries don't all work right on
it yet).  I confess I don't really understand the OpenJDK community that
well.

Anyway, I'm hoping to be able to move to Cacao/OpenJDK 7 in production next
year about this time  :-)  Until then I'm still in the Sun cargo cult.

On Wed, Aug 12, 2009 at 9:45 AM, Tal Liron wrote:

> Isn't the OpenJDK using the same codebase as Sun's? Rob, have you done
> any testing with OpenJDK at all?
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382905

Re: CPU at 100%

[Rob Heittman]

This was apparently fixed in 6U4:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2147719 /
http://java.sun.com/javase/6/webnotes/6u4.html.

We use Ubuntu distributions from Hardy thru Jaunty, which are tracking much
more recent JDKs; 6U11 on Hardy I believe and 6U13 on Jaunty.  Even my
customers on RHEL 5.3 have 6U11 now, though.

This bad bug is only one of the many that made anything earlier than about
6U9 unusable for us on Linux in production.  I don't know if the issues are
as severe on other platforms, but we could not even move from Java 5 to Java
6 in heavy load production until 6U9 -- we were loading our own javax.script
jars etc. to get to Java 6 features.  We had JVM crashes, 100% CPU
utilization, and all kinds of other fun.

I am happy to report, though, that at this point we can fire up a server
with Jaunty, install the default Sun JDK packages, and run it full bore with
Jetty NIO and scripting.  (Jaunty's OpenJDK/Cacao support looks promising
and performant, but has bizarre and plain scary bugs -- still need Sun
package for now!)

- R

On Wed, Aug 12, 2009 at 1:46 AM, Tal Liron wrote:

> It can affect any user of java.nio, unless that user implements a rather
> dumb workaround involving constantly destroying and recreating the
> selector, which obviously creates a performance hit. As I understand it,
> this workaround has been introduced into Grizzly 2.0, but I don't know
> about other frameworks. Since this is a bug specific to specific
> versions of the JDK on a specific platform, my guess is that some
> developers would prefer not to put this workaround into their main code
> branches, and delegate the problem to the user. This is especially true
> when there are so many nio frameworks around, and they often compete for
> performance.
>
> I should point out that this bug may not be easy to discover. 100% CPU
> does not mean that the application stops. In fact, your application will
> probably seem to run just fine. So, the only way to find this out is via
> OS or VM monitoring tools. In my case, I got a friendly email from my
> hosting provider asking me to stop stealing CPU cycles. :)
>
> Since Restlet users are heavy users of nio, I'm hoping someone else
> pipes up on the mailing list with more info...
>
> -Tal
>
> On 08/12/2009 12:33 AM, David Fogel wrote:
> > Hi Tal-
> >
> > Is it your opinion that this bug is likely to effect the
> > simpleframework connector as well?  If so, yikes.
> >
> > -Dave
> >
> > --
> >
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382784
> >
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382787
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382883

bug: riap://host and attachDefault

[Rob Heittman]

In snapshot (and probably since forever):

riap://host doesn't work if a Restlet is attached to a VirtualHost using
attachDefault instead of attach(pattern,target); an NPE is thrown in
ComponentClientDispatcher.

This is because setCurrent(hashCode) only gets called inside Routes created
by VirtualHost.createRoute(), and VirtualHost.createRoute() is not invoked
for the default attachment point.

I didn't see a no-brainer way to patch, since VirtualHost.attachDefault(...)
relies on super.attachDefault(...) to get its Route.

Should I bother filing a bug on this?  Or somebody just recommend the
approach to fix it and I'll send in a patch.

- R

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382642

Re: OSGi vs. Service Provider patterns

[Rob Heittman]

At one point I was given to understand that Equinox was the only OSGi
framework that yet understood fragments.  I'd be worried about going the
fragment route if that's still true.  But if KF and Felix and friends now
grok fragments (or will soon), I think that would be a lovely way to
repackage all the Restlet stuff for my purposes too.

On Tue, Aug 11, 2009 at 11:23 AM, David Fogel  wrote:

> 2) I prefer, and currently use via a custom build, the bundle
> _fragment_ approach for restlet extensions.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382554

Re: OSGi vs. Service Provider patterns

[Rob Heittman]

The additional dependency on the OSGi API in core (even though it is minor),
and the ripple of this across the Restlet ecosystem, were what made this a
non-starter before.  I really think using the new conditional compilation
support (editions) is the way to go.

Dave, if you're still listening, don't you have a more OSGi-friendly Restlet
custom build already?  If Jerome is OK with that direction, maybe we can
pool our resources and submit a patch.

On Mon, Aug 10, 2009 at 6:35 PM, Robin Hayman  wrote:

> Isn't the solution to making things work under OSGi to use the tools that
> OSGi provides?
>
> When a new extension bundle comes on line it implements RestletExtension
> then registers:
> bc.registerService( RestletExtension.class.getName(),null,null);
>
> When something wants to find it, it uses:
> (something like):
> servRefs = bc.getServiceReferences( RestletExtension.class.getName(),null);
> which finds all RestletExtensions, or, it can be specific, or use a filter.
>
> Such code does not take up much room because all it needs is the osgi api.
>  It can be mixed in with existing code with:
>  if(osgi-framework-present) do-it-this-way, if not do-it-the-other-way.
>
> Or use conditional compilation directives if we're counting bytes.
>
> It probably needs to be a bit more complicated to avoid start-up order
> dependencies and get into ServiceTrackers.
>
> It is hard to be OSGi without using OSGi conventions.  It is hard to do
> things right if the only tool available is a jar manifest tweak.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382231
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382459

Re: cookies and port number

[Rob Heittman]

As far as I know: Restlet does not track the RFC 2965 Set-Cookie2 behavior,
and RFC 2109 Set-Cookie cookies do not have a means of restricting by port.
Although RFC 2965 was introduced in 2000, Set-Cookie2 was pretty much
academic until recently -- the bulk of browsers in the wild did not support
it.  I think this is no longer true; a lot of modern browsers understand RFC
2965 cookie headers, enough that frameworks should care.

I suspect a little thinking is necessary before this can be implemented in
Restlet, though.  It would not be very nice to bloat responses by sending
both Set-Cookie and Set-Cookie2 headers, and I'd hate to get into the mode
of trying to track which user agents support it and which don't.  Perhaps if
Restlet extends CookieSetting to support RFC 2965 nuances like port, and
someone sets these extended values, this could trigger the insertion of the
extra Set-Cookie2 header; otherwise if Set-Cookie does the job it can be
relied on alone.

As a workaround for your app right now, I think you can use Restlet's
non-standard header mechanism (
http://www.restlet.org/documentation/2.0/api/org/restlet/data/Message.html#getAttributes%28%29)
to explicitly create the Set-Cookie2 header yourself.  If this works out, it
would be nice to create an RFE for RFC 2965 cookie support and share your
experiences and/or a patch  :-)  I wouldn't mind adding this capability to
my Restlet based applications either.

- R

On Mon, Aug 10, 2009 at 7:29 AM,  wrote:

> Hello,
>
> AFAIK cookies allow for specifying a port-parameter that ties the cookie to
> that specific port (in fact, I am getting a little confused between RFC 2109
> and RFC 2965 and couldn't work out which was the one to look at, so pardon
> me, if I am mistaken).
>
> CookieSetting doesn't allow for a port parameter to be specified. I assume,
> this is something rarely required anyway. However, it would be most helpful
> for me in my current project, so I was wondering if anyone could think of a
> way to get that parameter in there. The cookie writing is done inside the
> engine so I can't think of a straight forward way to add in my own little
> bit of code.
>
> Any hints are very much appreciated, thanks in advance
> Stefan
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382035
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382097

Re: Restlet 2.0 M4 released!

[Rob Heittman]

I really like the JSE/JEE edition idea; this has been the #1 source of
Restlet newbie questions I have gotten in real life when people try to
maintain one of our Restlet based apps.  Typically we develop *outside* a
JEE environment (my feelings about JEE are well known...) but often some
other team has the requirement to bring an app we wrote into an existing JEE
ecosystem.  Simply being able to switch the Restlet edition will be much
more comprehensible and documentable.

It strikes me that an OSGi edition might be a way to circle back to some of
the conceptual differences (service locator patterns, etc) that we left
hanging in various OSGi related threads.  Is there already an RFE for that?
Tigris refuses to speak to me right now.

- R

On Fri, Aug 7, 2009 at 3:34 AM, Jerome Louvel wrote:

> Hi guys,
>
> The reasoning is that we you plan to use Restlet in a Java EE container,
> all you really need is the Servlet adapter extension. During
> development/prototyping, you could use the internal HTTP server and
> client connectors to do quick tests.
>
> Dustin, what is your use case requiring both the Servlet and the Simple
> extensions?
>
> Cheers,
> Jerome
>
>
> Thierry Boileau a écrit :
> > Hi Dustin,
> >
> >  >the fact that the simple extension is missing from the jee extension
> > is a bug, I've updated the svn repository.
> > I'm not very well waken up... Actually , it was chosen to remove the
> > "server" connectors from the jee edition except the "servlet" extension.
> > But as said previously, we can reconsider this.
> >
> > Best regards,
> > Thierry Boileau
> >
> >
> >
> >> Hi Dustin,
> >>
> >> the fact that the simple extension is missing from the jee extension is
> >> a bug, I've updated the svn repository.
> >> It has ben chosen to exclude the servlet extension from the "jse"
> >> edition and integrate it inside the "jee" one. The latter can be
> >> consider as the jse edition plus the support of the servlet and all
> >> features that rely on servlet.
> >> Having said that we are totally open to reconsider the question, and
> >> ameliorate what we consider as a proposition.
> >>
> >> Best regards,
> >> Thierry Boileau
> >>
> >>
> >>
> >>> Great work guys, thanks!
> >>>
> >>> I need features from both the jse, and the jee versions though (i.e.
> >>> Simple is missing from the jee version, and servlet is missing from the
> >>> jse version).  Is it best to download both, then merge them?
> >>>
> >>> Thanks,
> >>> Dustin
> >>>
> >>>
> >>> Jerome Louvel wrote:
> >>>
> >>>
> >>>
>  Hi Restleters,
> 
> 
> 
>  We are happy to announce our latest 2.0 milestone:
> 
>  http://blog.noelios.com/2009/08/06/restlet-2-0-m4-released/
> 
> 
> 
>  We have received an incredible amount of contributions since 2.0 M3:
>  thank you all!
> 
> 
> 
>  I want also like to highlight the key work done by Thierry, behind the
>  covers, to bring you a fully automated port of all editions (Java SE,
>  Java EE, GWT, GAE and Android) from a single code base. He also
>  greatly improved our build system to provide dedicated distributions
>  for each edition!
> 
> 
> 
>  Best regards,
>  Jerome Louvel
>  --
>  Restlet ~ Founder and Lead developer ~ http://www.restlet.org
>  
>  Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>  
> 
> 
> 
> 
> 
> 
> 
> 
> >>>
> >>>
> >> --
> >>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2381196
> >>
> >>
> >>
> >
> > --
> >
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2381203
> >
> >
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2381204
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2381314

Re: Restlet 2.0 M4 released!

[Rob Heittman]

The automated ports are deeply magical and awesome and I hope you do
presentations at lots of conferences about them.  I know what a huge pain it
was to do the first GWT port ... to have all these platform ports at the
push of a button is just amazing.

On Thu, Aug 6, 2009 at 12:52 PM, Jerome Louvel wrote:

>  Hi Restleters,
>
>
>
> We are happy to announce our latest 2.0 milestone:
>
> http://blog.noelios.com/2009/08/06/restlet-2-0-m4-released/
>
>
>
> We have received an incredible amount of contributions since 2.0 M3: thank
> you all!
>
>
>
> I want also like to highlight the key work done by Thierry, behind the
> covers, to bring you a fully automated port of all editions (Java SE, Java
> EE, GWT, GAE and Android) from a single code base. He also greatly improved
> our build system to provide dedicated distributions for each edition!
>
>
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2380963

Re: Export Classification

[Rob Heittman]

Just offering an unofficial opinion in case Jerome looks at this and thinks
"silly Americans, what do they mean?"  I was actually going to suggest you
look to IBM for this info and then I saw your reply address  :-)

Here is what ASF did to document the Export Classification stuff; we could
create a similar page on Restlet Wiki somewhere:

http://www.apache.org/licenses/exports/

The relevant bit is this: Products classified as ECCN 5D002 (crypto and
users of crypto), should follow the TSU exception in EAR
740.139(e),
which applies to software containing or designed for use with encryption
software that is publicly available as open source.

Since this horse has been out of the barn for a long time, maybe the present
administration can make this software-as-a-munition nonsense materially go
away.  Here's hoping.

- Rob

On Wed, Jul 29, 2009 at 1:34 PM, Jennifer Carlucci wrote:

>
> Does Restlet have an Export Classification?
>
> Thanks,
> Jennifer Carlucci
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2376927

Re: RIAP Client from within my J2EE application (jboss)

[Rob Heittman]

Can you try riap://host instead of riap://component and see if that works
for you?  This is kind of cargo cult advice but we have mainly changed to
that, and it works.  Untested hypothesis: component/application context
visibility issues (added for security reasons around 1.2M2 IIRC) prevent you
from using riap://component from an Application context.

On Wed, Jul 29, 2009 at 7:44 PM, Andrew Moore wrote:

> I thought at one point I could call the static method "getCurrent()" on my
> Application (i.e. MyRestletApplication.getCurrent()) and then make my riap
> request through there:
>
>
> MyRestletApplication.getCurrent().getContext().getClientDispatcher().get("riap://component/path-to-my-resource")
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2376774

Re: Guidance on Atom/APP in Restlet

[Rob Heittman]

All valid points.  There must be cooperation between a client and server at
some level!

I have two problems with RPC style implementations on the Web:

1) The RPC paradigm hides the advanced properties of the Web and makes them
really difficult to leverage

2) The RPC protocol and serialization behavior is totally opaque to any
client or server not using a compatible RPC library, of which (as in GWT)
there is usually only one, in one language.

Jerome's proposed use of the GWT RPC serialization works around both of
these objections.  Objection #1 goes away because the serialized
representations are exposed using Restlet.  Objection #2 goes away for two
reasons:

a) (weak) The GWT RPC serialization is not really very opaque (compared to,
say RMI tunnelled over HTTP).  It's JSON and, while terse, not beyond
comprehension.  I have actually written stuff to do GWT RPC server interop
with non-GWT clients, and it's possible, if yucky.

b) (strong) Restlet makes it trivial to expose alternate variants (e.g. XML,
HTML) for other clients, which you just can't do with RPC alone.

So I'm signed up for the serialization train.

- R

On Sat, Jul 25, 2009 at 5:44 AM, Jerome Louvel wrote:

> But wait! XML and JSON do introduce coupling as you need to know their
> structure in advance most of the time! If you want an even less coupling,
> then looking towards RDF is a good idea but still you will need to
> understand some ontologies...
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2375529

Re: Wikipedia Restlet entry

[Rob Heittman]

Thanks, that was helpful to make a start.

On Tue, Jul 21, 2009 at 8:41 AM, Jerome Louvel wrote:

>  Rob,
>
>
>
> Sounds like a good approach indeed.
>
>
>
> To answer your question about press coverage, here are two pointers from
> InfoQ:
>
> http://www.infoq.com/restlet
>
>
>
> Two from eWeek:
>
> http://www.eweek.com/c/a/Application-Development/Restlet-Engine-Reaches-10/
>
>
> http://www.eweek.com/c/a/Application-Development/Java-Project-Founder-Outlines-Benefits-of-Restlet/
>
>
>
> One from ComputerWeekly:
>
>
> http://www.computerweekly.com/Articles/2006/09/12/218314/open-tool-makes-it-easier-to-develop-web-services.htm
>
>
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
>
>
>
>
> *De :* Rob Heittman [mailto:rob.heitt...@solertium.com]
> *Envoyé :* mardi 21 juillet 2009 14:15
> *À :* discuss@restlet.tigris.org
> *Objet :* Re: Wikipedia Restlet entry
>
>
>
> I agree you should avoid it, they get grumpy about that. Anyone know of any
> Restlet coverage in main stream media or other citable support for
> notability?
>
> On Tue, Jul 21, 2009 at 4:47 AM, Jerome Louvel 
> wrote:
>
> Hi guys,
>
> Thanks for updating this entry. Ive been reluctant to touch it so far, as I
> think it should provide a neutral presentation of Restlet. So, it would be
> better if the Restlet users could maintain it.
>
> However, Ill be happy to read and comment. For example, I noticed that the
> new EPL 1.0 licensing option isnt mentioned. Regarding the history, the
> development started in 2005 with a first public release in December 2005
> (instead of 2006). I have a couple more article pointers to add if
> necessary.
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder~ http://www.noelios.com
>
> *De:* Aron Roberts [mailto:a...@socrates.berkeley.edu]
> *Envoy**頺* lundi 20 juillet 2009 21:04
> *:* discuss@restlet.tigris.org
> *Objet:* Re: Wikipedia Restlet entry
>
> In the message "Wikipedia Restlet entry", dated 2009-07-20, Rob Heittman
> wrote:
>
> Stumbled across this: http://en.wikipedia.org/wiki/Restlet
>
>  Currently on probation for not meeting notability standards. Anybody else
> (Jerome, Thierry) want to volunteer with me to help doctor up the entry and
> provide relevant citations? Any Restleters with good Wikipedia karma would
> be welcome too.
>
>  Many thanks for pointing this out, Rob.
>
> I've made a few, very minor updates to that Wikipedia page today as a
> starting point, and to encourage others to jump in. :-)
>
> Aron Roberts Information Services and Technology . Warren Hall, 2195 Hearst
> University of California, Berkeley, CA 94720-4876 USA
> a...@socrates.berkeley.edu . +1 510-642-5974 . fax 510-643-5385
> http://purl.org/net/aron
>
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372986

Re: Wikipedia Restlet entry

[Rob Heittman]

I agree you should avoid it, they get grumpy about that.  Anyone know of any
Restlet coverage in main stream media or other citable support for
notability?

On Tue, Jul 21, 2009 at 4:47 AM, Jerome Louvel wrote:

>  Hi guys,
>
>
>
> Thanks for updating this entry. I’ve been reluctant to touch it so far, as
> I think it should provide a neutral presentation of Restlet. So, it would be
> better if the Restlet users could maintain it.
>
>
>
> However, I’ll be happy to read and comment. For example, I noticed that the
> new EPL 1.0 licensing option isn’t mentioned. Regarding the history, the
> development started in 2005 with a first public release in December 2005
> (instead of 2006). I have a couple more article pointers to add if
> necessary.
>
>
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
>
>
>
>
>
>
> *De :* Aron Roberts [mailto:a...@socrates.berkeley.edu]
> *Envoyé :* lundi 20 juillet 2009 21:04
> *À :* discuss@restlet.tigris.org
> *Objet :* Re: Wikipedia Restlet entry
>
>
>
> In the message "Wikipedia Restlet entry", dated 2009-07-20, Rob Heittman
> wrote:
>
>
>
> Stumbled across this: http://en.wikipedia.org/wiki/Restlet
>
>  Currently on probation for not meeting notability standards.  Anybody
> else (Jerome, Thierry) want to volunteer with me to help doctor up the entry
> and provide relevant citations?  Any Restleters with good Wikipedia karma
> would be welcome too.
>
>
>
>   Many thanks for pointing this out, Rob.
>
>
>
>   I've made a few, very minor updates to that Wikipedia page today as a
> starting point, and to encourage others to jump in. :-)
>
>
>
> Aron Roberts  Information Services and Technology . Warren Hall, 2195
> Hearst
>   University of California, Berkeley, CA 94720-4876 USA
>   a...@socrates.berkeley.edu . +1 510-642-5974 . fax
> 510-643-5385
>   http://purl.org/net/aron
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372934

Wikipedia Restlet entry

[Rob Heittman]

Stumbled across this: http://en.wikipedia.org/wiki/Restlet

Currently on probation for not meeting notability standards.  Anybody else
(Jerome, Thierry) want to volunteer with me to help doctor up the entry and
provide relevant citations?  Any Restleters with good Wikipedia karma would
be welcome too.

- R

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372503

Re: Wiring restlets internally (2.0snapshot from 2009-07-09)

[Rob Heittman]

For inter-resource communication we tend to use the RIAP pseudoprotocol:

http://wiki.restlet.org/docs_1.2/13-restlet/48-restlet/86-restlet/45-restlet.html

This correctly provides all the relevant routing and construction behavior.
It is cheaper than making an actual http request to localhost or something
abominable like that, but still a bit expensive as the full Restlet
infrastructure is invoked each time.

I think the cheapest choice is to factor out the interesting behavior you're
trying to avoid duplicating into a separate function or class, and call it
directly in both places -- but this choice may be too brittle or not
possible for other reasons specific to the resources.

On Wed, Jul 15, 2009 at 11:40 AM, Fabian Mandelbaum
wrote:

> Is this the correct way to wire restlets internally? Is there any
> other (more elegant, more performant, "just working", whatever)
> solution to this problem?
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2371514

Re: Designing restlet applications

[Rob Heittman]

Theory again ...
Content negotiation seems beautiful, although popular user agent support has
always been weak.  Imagine a set of buttons that manifests on your browser
with little icons to let you know when the current page is also available in
Word, PDF, RSS,
etc ... wouldn't that be cool?  Well, we sort of have that with RSS in
many browsers, but it doesn't use HTTP content negotiation.
 How about different languages ... I'd love to know that the Noelios page is
available in French as well as English and push a convenient button to
switch.  But, no, and even if your browser is fortunate enough to have the
feature, it's neither obvious nor easy to use.

Plus, there is no easy way in HTTP content negotiation to differentiate
between different versions of the same mime-type (e.g. text/html) for
different purposes.  Mobile version, printer friendly version, etc.  If
these are the same language and same mime-type, even assuming the magic
browser features existed that don't exist, we still wouldn't have the
facilities in HTTP to effectively address these functional variations on the
same general representation type.

So we end up putting different variants behind different URIs, so we can put
idiot proof links in an HTML page and say "Click here for printer friendly
version."  Semantically this is just wrong.  We're addressing the same
resource (same logical end target) but a different representation -- it
should have the same URI.  Nevertheless, it's what we have to do in a "Web
1.0" browser based web app.

What we did in our GoGoEgo CMS (http://gogoego.googlecode.com) was to
canonize URIs of the form

[data-resource]/[template]

for decorated HTML pages.  The last token of the URI is used as a lookup
into a registry of decorator templates that can pull on the content of the
data resource and make a different representation of it, so your "case
1, /user/1/print" is blessed as The Solution in our CMS.  Evidence from our
3 or 4 integrators so far is that this can be used very productively.

Restlet doesn't really help us with this aspect; we have this one Filter
class called GoGoMagicFilter which centralizes all the abominations
necessary to implement this templating, as well as trigger the scripting
integration, header manipulations, and other misbehaviors that make the
HTML/browser/Web 1.0 world livable.  And whenever anyone proposes a change
to GoGoMagicFilter, a groan goes up and many palms go to faces.

Case 5 is so close, but you're right, it's wrong.  If there was ever another
swing taken at extending RFC 2616 the only one thing I would want to help
design in is a standard request/response header pair that existed to pass
application-specific "purpose" information -- that behaved like Accept but
with application-defined semantics.  Stuff like "Printer view" and "Mobile
view" comes up all the time, as do similar themes in pulling feeds (preview
length...) and image galleries (size...).  Maybe there is room for a new RFC
like WebDAV RFC 2518 that canonizes some of this.  Then, with capable Web
2.0 intelligent clients, I would have a vocabulary for making these
functional variants appear under the same URI as I do with other language or
mime-type based variants.

Anyway, that's just wishful thinking for now ... I have embraced "case 1"
and, as the country song goes, that's my story and I'm stickin' to it.

- R

On Sat, Jun 20, 2009 at 8:22 PM, William Pietri  wrote:

>  Rob Heittman wrote:
>
> I find that I've had a hard time implementing complete template-based,
> page-based UIs entirely on the server without making a mess.  I think
> this is because I'm just conflating too many UI concerns in one layer.
>
>
> I've had that feeling recently, too.
>
> Would people be willing to share examples of how they've done this with
> Restlet? For example, the other day we needed to create a print view of one
> of our entities. Sticking with the user example, these options occurred to
> us, in rough order of preference:
>
>
>1. /user/1/print
>2. /user/1?view=print
>3. /user/print/1
>4. /print/user/1
>5. /user/1 (with a custom media type in the Accept header)
>6. /user/1 (with a POST that requests the print view)
>
>
> The last 4 all strike me as various flavors of wrong. I'm ok with the first
> two, but neither seems great to me, in that the URLs suggest different
> resources, while we think of the print view as a different representation of
> the same resource.
>
> Since none of the folks on my team feel like we fully get what a RESTful
> web app looks like, I'd love to hear how more experienced people do it.
>
> William
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363870

Re: Lift framework in Scala

[Rob Heittman]

I found the same link you did after my curiosity was piqued by a tweet that
seems to be unreachable from Twitter search now (may have scrolled off) but
came up on a search for Restlet last week.  Someone tweeted that they
rewrote their Restlet application in Lift in a fraction of the time.  Having
looked at Lift a bit now, I'd love to see that application!
On Wed, Jun 17, 2009 at 3:10 AM, Jerome Louvel wrote:

> Hi Rob,
>
> I'm not familiar with Lift either.
>
> Do you have some pointers to those discussions/tweets? I've been able to
> find this one but it doesn't go very far regarding the comparison with
> Restlet:
>
> http://groups.google.com/group/liftweb/browse_thread/thread/32e45046dadff642
> /
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -Message d'origine-
> De : Rob Heittman [mailto:rob.heitt...@solertium.com]
> Envoyé : mercredi 17 juin 2009 03:34
> À : discuss@restlet.tigris.org
> Objet : Lift framework in Scala
>
> Hi all,
>
> The long term residents here know I'm kinda partial to Scala.  I've
> seen a couple of tweets and blogs lately favorably comparing Lift
> (http://liftweb.net/) to Restlet and thought it might be appropriate
> to begin a little bit of a comparative exercise.
>
> I haven't tried to do anything real with Lift yet.  I get a bit of a
> chaotic impression, but haven't met with a developer using it in
> production yet, and haven't tried anything other than a toy
> application yet.  Perversely it feels a bit Django-esque to me, which
> I suspect means I'm missing the point somehow.
>
> Any Restlet fans have experience with Lift or any suggestions for
> outreach/interchange with the Lift community?  Advice from Noelios on
> how to explore this territory?
>
> Great Ghu, my title is showing.
>
> - R
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23626
> 71
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2362695
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2362837

Lift framework in Scala

[Rob Heittman]

Hi all,

The long term residents here know I'm kinda partial to Scala.  I've
seen a couple of tweets and blogs lately favorably comparing Lift
(http://liftweb.net/) to Restlet and thought it might be appropriate
to begin a little bit of a comparative exercise.

I haven't tried to do anything real with Lift yet.  I get a bit of a
chaotic impression, but haven't met with a developer using it in
production yet, and haven't tried anything other than a toy
application yet.  Perversely it feels a bit Django-esque to me, which
I suspect means I'm missing the point somehow.

Any Restlet fans have experience with Lift or any suggestions for
outreach/interchange with the Lift community?  Advice from Noelios on
how to explore this territory?

Great Ghu, my title is showing.

- R

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2362671

Re: Restlet GWT - ChallengeResponse null on server side

[Rob Heittman]

Hi Max,
I'm having some trouble understanding your use case too.  Sorry if
maybe it is just a language problem.  Let me try to repeat this to see
if I understand.

- You have already created a Restlet service which is out on the web
somewhere, say http://publicserver/restlet/service.

- You need to create a client application, using GWT, which will consume
this Restlet service.

Once you compile your GWT application to Javascript, if you install the
resulting HTML and JS at http://publicserver/gwt, it will be able to access
the service, because it is on the same server.

However, when you are running in GWT Hosted Mode for debugging purposes,
against your local GWT Hosted Mode Tomcat server at http://localhost:,
you can not access the service due to sandbox restrictions, because it is on
http://publicserver instead.

If so, you can work around this using Restlet's Redirector feature, and
org.restlet.ext.gwt or org.restlet.ext.servlet.  In hosted mode, your
development client will make requests to
http://localhost:/some-restlet-route and Restlet will forward them to
the real server on http://publicserver/restlet/service.

I'm not sure if this is what you're trying to do, but if it is let me know
and I can walk you through this in more detail.

- Rob

On Tue, Jun 16, 2009 at 6:03 PM, mstricker  wrote:

> Hi,
> I upgraded both my server & GWT libs to 1.1.5 as you suggested.
> I use Firefox 3 as browser under Windows XP and Mac OS X Leopard.
> The updated not fix my issue but I think I know the cause,
>
> I think it is because of the security restrictions ( RPC calls can be made
> only to the same host).
> I had a look at the deployment instruction from your wiki but I think it
> does not correspond to my situation.
>
> I have a Restlet service finished and deployed which is used by mobile
> devices as clients.
> Now I have to enable 2-3 functionalities over the web, and I am forced to
> use GWT, altough I havent used it til now.
> So I think i do not need the "server" part of GWT, since my service is
> ready to be consumed.
> I thought about using restlet.gwt to consume it and display the results.
> But this does not work
> since I cannot deploy the html files to my tomcat to have the same url and
> can make the calls to the service.
> How is such a sittuation going to be solved?
> I assume something with apache/mod_proxy? Can someone guide me how to solve
> it,
> as I am not a sysadmin and cannot touch many things on the tomcat instance.
>
> Thans for any advice
>
> Max
>
> Am 16.06.2009 um 22:35 schrieb jlouvel (via Nabble):
>
> Max,
>
>
>
> I suggest that you upgrade to Restlet 1.1.5. This might fix your issue.
>
>
>
> Otherwise, which browser and OS are you using on the client side?
>
>
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
>
>
> *De :* mstricker 
> [mailto:m...@...]
>
> *Envoyé :* mardi 16 juin 2009 22:28
>
> *À :* 
> disc...@...
> *Objet :* Re: Restlet GWT - ChallengeResponse null on server side
>
>
>
> Hi,
>
>
>
> thanks for your reply. I waited the whole day.
>
> Here my configuration:
>
>
>
> Apache Tomcat/6.0.18
>
> JVM Version 1.6.0_07-b06
>
> restlet 1.1.1
>
>
>
> I followed the instructions from the wiki, and my test code is realy simple
> at the moment:
>
>
>
> on server side i simply log getRequest().getChallengeResponse() which is
> null
>
>
>
> the GWT client is also realy simple and is basically copied from the wiki:
>
> org.restlet.gwt.data.Request request = *new* org.restlet.gwt.data.Request(
>
>Method.*GET*,
>
>"
> http://cmydomain.com:8080/myServicet/authenticate";);
>
>ChallengeResponse authentication = 
> *new*ChallengeResponse(
>
>ChallengeScheme.*HTTP_BASIC
> *, 
> "t...@...
> ",
>
>
> "098f6bcd4621d373cade4e832627b4f6");
>
>
>
>
>
> request.setChallengeResponse(authentication);
>
>System.*out*.print(request);
>
>Client client = *new* Client(Protocol.*HTTP
> *);
>
>
>client.handle(request, *new* Callback() {
>
>@Override
>
>*public* *void* onEvent(Request
> request, Response response) {
>
>System.*out*
> .println(response.getEntity().getText());
>
>}
>
>});
>
> I test the GWT code using the hosted mode from my local machine, the server
> part is deployed to a tomcat instance on the w

Re: Restlet 2.0 M3 released

[Rob Heittman]

And 4. that new RepresentationInfo thing is pure nitroglycerine.
Thanks for validating trunk, Tal, I had to hold off on some port attempts on
my end due to the 406 problem ... I'll give it another whirl.

On Tue, Jun 16, 2009 at 2:30 PM, Tal Liron wrote:

> 1. Routing: Routing seems to be being reworked. I'm not sure how it will
> look for the final release as of yet, but the RFEs point to some very
> useful abilities.
> 2. High-level HTTP: ServerResource is a revolution in this regard.
> Annotations will allow a very concise way of defining the rules for
> negotiation. And the advent VariantInfo class (with the getInfo methods)
> can really improve performance for negotiation. (I'm think there should
> be a tutorial to show this in action.)
> 3. Representation: The advent of the ConverterService makes it easy to
> handle transformations across the entire application/service.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2362566

Re: Designing restlet applications

[Rob Heittman]

I was starting to answer this and realized I was making an assumption.
 WHY don't you want to do this?  (Too many routes?  Don't like the URI
hierarchy that's emerging?)

I find that I've had a hard time implementing complete template-based,
page-based UIs entirely on the server without making a mess.  I think
this is because I'm just conflating too many UI concerns in one layer.
 If I have a GWT, AJAX, Flex, Swing or other rich client UI, the REST
back end remains clean and simple.

On Tue, Jun 16, 2009 at 1:26 AM, Matt wrote:
> I don't really want to do this if I can avoid it.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2362455

Re: Calling Restlet from Restlet

[Rob Heittman]

I think you're looking for the Restlet Internal Application (Pseudo)Protocol
(riap://):
http://www.restlet.org/documentation/2.0/api/org/restlet/data/Protocol.html#RIAP

I was just having a look at the wiki documentation for this and it could
stand to be freshened, but the general idea is that riap://(authority)/path
will do an internal request.  We use it *heavily* as, I believe, do some
other major Restlet adopters.  There have been some changes as to what the
valid authority strings are ... "application" "component" and "host" have
all worked under various Restlet versions.  I will see if I can't update the
wiki to be correct for 1.1 and 2.0 in the near future.

- R

On Fri, Jun 12, 2009 at 10:19 AM,  wrote:

> I need to invoke a Restlet from a Restlet. I can make a call to the Restlet
> just like a client but can I do that using a relative URL (/foo) or does it
> need the full URL (http://www.mydomain.com/foo)?
>
> Or would it be better to use Redirector
>
> String target = "/foo";
> Redirector redirector = new Redirector(getContext(), target,
> Redirector.MODE_CLIENT_TEMPORARY);
>
> If Redirector, what method actually invokes the redirect?
>
> Thank you,
>
> Perry Hoekstra
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361623
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361697

Re: Re: Re: Last-Modified Header

[Rob Heittman]

Excellent.  I missed that one in the mix of ServerResource newness!  I'll
try it out on some expensive Representations and publish a benchmark.

On Thu, Jun 11, 2009 at 9:23 AM, Jerome Louvel wrote:

>  Hi Rob,
>
>
>
> Actually, we did try to facilitate this use case in Restlet 2.0. We
> introduced the RepresentationInfo class, subclass of Variant and parent of
> Representation. It contains two properties, “modificationDate” and “tag”,
> necessary for conditional processing.
>
>
>
> In ServerResource, there are also getInfo() and getInfo(Variant) methods
> which return RepresentationInfo instances. By default, it calls get() and
> get(Variant) methods, so it is really an optional optimization.
>
>
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
>
>
>
>
> *De :* Rob Heittman [mailto:rob.heitt...@solertium.com]
> *Envoyé :* mercredi 10 juin 2009 19:23
> *À :* discuss@restlet.tigris.org
> *Objet :* Re: Re: Re: Last-Modified Header
>
>
>
> I can't imagine how the framework would be able to figure that out on its
> own without being able to examine the Representation ... chicken, egg,
> chicken, egg.
>
>
>
> Still, I understand the concern if Representations are expensive to
> generate.  I wonder if the conditional logic fetches the entity body if the
> last modified date has not changed.  If it doesn't (and it probably
> shouldn't) then you could just craft a Representation subclass in which the
> expensive stuff only happens when the entity body is actually read -- the
> headers should be enough to tell the engine how to handle the conditional
> GET.
>
>
>
> ** disclaimer ** I really don't know if that approach works, but I think it
> ought to.
>
>
>
> - Rob
>
> On Wed, Jun 10, 2009 at 1:11 PM, Sherif Ahmed 
> wrote:
>
> Cool,
>
> This works as you indicate. However implementing this way has a downside.
> Would be nice that the framework could take care of sending a 304 even
> without having to get a concrete Representation which has a date set.
>
> The idea is to avoid creating a Representation if the Resource has not
> changed and Restlet could send a 304 directly thus avoiding the cost that
> may be associated with building a Representation.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361007
>
>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361296

Re: Re: Re: Last-Modified Header

[Rob Heittman]

I can't imagine how the framework would be able to figure that out on its
own without being able to examine the Representation ... chicken, egg,
chicken, egg.
Still, I understand the concern if Representations are expensive to
generate.  I wonder if the conditional logic fetches the entity body if the
last modified date has not changed.  If it doesn't (and it probably
shouldn't) then you could just craft a Representation subclass in which the
expensive stuff only happens when the entity body is actually read -- the
headers should be enough to tell the engine how to handle the conditional
GET.

** disclaimer ** I really don't know if that approach works, but I think it
ought to.

- Rob

On Wed, Jun 10, 2009 at 1:11 PM, Sherif Ahmed wrote:

> Cool,
>
> This works as you indicate. However implementing this way has a downside.
> Would be nice that the framework could take care of sending a 304 even
> without having to get a concrete Representation which has a date set.
>
> The idea is to avoid creating a Representation if the Resource has not
> changed and Restlet could send a 304 directly thus avoiding the cost that
> may be associated with building a Representation.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361007
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361011

Re: Last-Modified Header

[Rob Heittman]

Underway, target 2.0M5: Add Encoder Service (Similar to Decoder Service)
http://restlet.tigris.org/issues/show_bug.cgi?id=208

I'm glad this one is somebody else's job!  Not easy to get right.

On Wed, Jun 10, 2009 at 12:47 PM, Sherif Ahmed wrote:

> Now does Restlet has a framework to take care of Gzip encoding results when
> the Request headers indicate that the request is from a client that supports
> this encoding (all modern browsers do)

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361006

Re: Pagination

[Rob Heittman]

Status code 303 (Status.REDIRECT_SEE_OTHER in Restlet) exists for the
POST/Redirect/GET case.  I'm not sure there's any "right" way vis a vis
returning an entity directly from a POST -- certainly that's useful too in
straightforward cases.  P/R/G is really helpful when the result is more
complex and may really consist of multiple GETable resources as in
pagination.
On Wed, Jun 10, 2009 at 11:54 AM, Dustin N. Jenkins <
dustin.jenk...@nrc-cnrc.gc.ca> wrote:

> I assume the POST/Redirect/GET pattern is the Client POSTing to the
> Resource, and instead of filling the Response's Entity with the
> Representation of the change, one simply redirects the Client to the GET
> representation.  Is this the desired behaviour?  I was under the
> impression that populating the Response's Entity in the POST was
> improper practice, but we often lazily do it.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2360979

Re: Re: Last-Modified Header

[Rob Heittman]

Restlet provides the 304 plumbing for you.  Just setModificationDate() on
your Resource's returned Representation as Jon suggests.  The GET headers
returned from my Web site which calls this function are below.  If you hit
this resource with Firefox and watch it with Firebug as you refresh (which
does conditional GETs), you'll see 304s being returned instead.  This is all
done by Restlet internally -- my code doesn't know anything about
conditional processing.

curl -I http://solertium.com/index.html
HTTP/1.1 200 OK
Expires: Wed, 10 Jun 2009 15:55:42 GMT
Content-Type: text/html; charset=UTF-8
Last-Modified: Wed, 10 Jun 2009 15:40:42 GMT
Content-Length: 11302
Date: Wed, 10 Jun 2009 15:40:42 GMT
Set-Cookie: BROWSERID=cQv0DC1n-c0fgM3-Jl; Path=/; HttpOnly
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Server: Noelios-Restlet-Engine/1.2.m1

On Wed, Jun 10, 2009 at 11:36 AM, Sherif Ahmed wrote:

> Thanks Jon.
>
> What I am trying to accomplish is implementing the Last-Modified /
> If-Modified-Since logic. Where I would tag responses with a uniform
> "Last-Modified" header for all resources/representations and when a request
> comes in with a "If-Modified-Since" header I'd send appropriate HTTP 304
> response or completely process the response.
>
> Ideas/Best Practices to accomplish this without having to get the
> HttpServletRequest/Response objects to do this would be great
>
> > Hi Sherif,
> >
> > For custom headers whatever name you give,  "entity.modificationDate",
> > will be used.
> >
> > However, what you probably meant to do is use setModificationDate(new
> > Date()) on the entity/response representation. ie.
> > representation.setModificationDate(new Date());
> >
> > Jon
> >
> > Sherif Ahmed wrote:
> > > I've been trying to add Last-Modified Header via the following code in
> a Filter afterHandle method
> > >
> > > Form responseHeaders = (Form)
> response.getAttributes().get("org.restlet.http.headers");
> > >
> > > if (responseHeaders == null)
> > > {
> > > responseHeaders = new Form();
> > > response.getAttributes().put("org.restlet.http.headers",
> responseHeaders);
> > > }
> > > responseHeaders.add("entity.modificationDate", "Sun, 06 Nov 2005
> 14:59:42 GMT");
> > >
> > >
> > > However the header in the HTTP Response is not "Last-Modified" as I
> would have expected, rather a custom header
> > >
> > > "entity.modificationDate: Sun, 06 Nov 2005 14:59:42 GMT"
> > >
> > > Quick response would be much appreciated
> > >
> > > --
> > >
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2360858
> > >
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2360959
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2360964

Re: Pagination

[Rob Heittman]

Yes, keeping the state bookmarkable for a complex search is also an
interesting challenge.  I know one web site (also a science app) that has
several hundred variables that can be incorporated in a query, more than a
bookmark would easily store.  They keep a permanent cache of search queries
in the database and return a "minified" URL, like bit.ly, using the
Post/Redirect/Get pattern.  They mark position in
pagination using query params:
http://{science-app}/search/afq1z?start=1564&extent=20

but I also like the "after" approach better:

http://{science-app}/search/afq1z?after=Sula+Nebouxi,Ecuador&extent=20

There are also nice properties of the minified query identifier URL, in that
it lends itself to subsequent RESTful interrogation in other ways:

http://{science-app}/search/afq1z/sql -- retrieve SQL query definition
http://{science-app}/search/afq1z/export/csv -- dump entire data set to CSV

or fun using Variants ... etc ...

On Tue, Jun 9, 2009 at 11:44 AM, Dustin N. Jenkins <
dustin.jenk...@nrc-cnrc.gc.ca> wrote:

> Hi Rob,
>
> Thank you very much for the detailed post.  It's very useful.
>
> My Persistence Layer uses Hibernate, which in turn uses ehcache as the
> Second Layer cache, but I've always had it turned off, so now would be a
> good time to experiment with it I suppose.
>
> A stable search result is not required in my case, and I would happily
> go back to the Persistence Layer each time as I deal with Scientific
> results that are updated all the time.  A user wouldn't necessarily get
> lost while moving from page to page.
>
> In reference to Josh's solution, I really like the idea of going by the
> sorted results and asking for the data after the last known item.  I
> deal with a multi-field form; upwards of a dozen fields to search on, so
> passing data back and forth may not be viable all the time, especially
> with a GET given the known character limitation.  However, do users
> commonly bookmark a search result with a page number?  I could
> definitely see it.  Perhaps the bookmark would encapsulate the AFTER
> clause in the URL.
>
> Thanks again, Rob.  It is an interesting problem.
> Dustin
>
>
> Rob Heittman wrote:
> > Ah, pagination.  One of the great programming tradeoffs  :-)  Have a
> > look at this comment thread from Ohloh a while back.
> >
> > http://www.ohloh.net/forums/3491/topics/1056
> >
> > Josh Triplett proposes a good solution that is lightweight for paging
> > non-critical data without server state.
> >
> > You can guarantee a stable search result for the duration of the
> > browse by caching the entire result set server side and providing a
> > means of moving through it ... that might scale to hundreds of
> > results, but not so much to millions.  Still, that's the usual Session
> > idiom.
> >
> > Here's what I usually do ... send an HTML or XML representation with
> > sufficient information about how to repeat the search and page thru
> > it, but keep no server side state per se.  I just make sure the data
> > layer is smart enough about caching result sets to avoid unnecessary
> work.
> >
> > Example: say I am exposing a fulltext search over a collection of
> > 10,000 documents and someone searches on "the".
> >
> > Client hits Resource (stateless, short lived) by POST to /search with
> > something like
> >
> > the
> >
> > Resource submits the search to a query service.
> > Query service hits fulltext index and gets 9,995 hits.  Caches this
> > result, "the"="{set of 9,995 hits}"
> > Resource consumes first 10 results from query service.  Sends
> > something like:
> >
> >  9995
> >  1
> >  10
> >  The first of many
> >  ...
> >  The tenth of many
> >
> > Let's say client wants the next page of results.  It immediately sends
> > back:
> >
> >  the
> >  11
> >
> > Resource asks query service for "the" again.
> > Query service fetches "the"="{set of 9,995 hits}" out of cache.
> > Resource consumes results 11-20 from query service ... etc.
> >
> > This approach is not guaranteed stable.  If the result set expires
> > from cache and also changes in between paginated queries you might end
> > up missing some results, ending up at 9,997 results instead of 9,995,
> > etc.  When you do soft stuff like Google searches, this happens all
> > the time (wait, my blog was on page 1 when I started ...)
> >
> > But if you were searching for credit card transactions, the
> &

Re: Pagination

[Rob Heittman]

Ah, pagination.  One of the great programming tradeoffs  :-)  Have a look at
this comment thread from Ohloh a while back.

http://www.ohloh.net/forums/3491/topics/1056

Josh Triplett proposes a good solution that is lightweight for paging
non-critical data without server state.

You can guarantee a stable search result for the duration of the browse by
caching the entire result set server side and providing a means of moving
through it ... that might scale to hundreds of results, but not so much to
millions.  Still, that's the usual Session idiom.

Here's what I usually do ... send an HTML or XML representation with
sufficient information about how to repeat the search and page thru it, but
keep no server side state per se.  I just make sure the data layer is smart
enough about caching result sets to avoid unnecessary work.

Example: say I am exposing a fulltext search over a collection of 10,000
documents and someone searches on "the".

Client hits Resource (stateless, short lived) by POST to /search with
something like
   
the
   
Resource submits the search to a query service.
Query service hits fulltext index and gets 9,995 hits.  Caches this result,
"the"="{set of 9,995 hits}"
Resource consumes first 10 results from query service.  Sends something
like:
   
 9995
 1
 10
 The first of many
 ...
 The tenth of many
   
Let's say client wants the next page of results.  It immediately sends back:
   
 the
 11
   
Resource asks query service for "the" again.
Query service fetches "the"="{set of 9,995 hits}" out of cache.
Resource consumes results 11-20 from query service ... etc.

This approach is not guaranteed stable.  If the result set expires from
cache and also changes in between paginated queries you might end up missing
some results, ending up at 9,997 results instead of 9,995, etc.  When you do
soft stuff like Google searches, this happens all the time (wait, my blog
was on page 1 when I started ...)

But if you were searching for credit card transactions, the instability
would be unacceptable.  Here, your search result set must be stored uniquely
and guaranteed to iterate forward and backward to the same conclusion until
the user goes away from it.

So instead of just repeating the search for "the" I would need to return a
unique key for the result set, that the server saved for me:

Client hits Resource (stateless, short lived) by POST to /search with
something like
   
the
   
Resource submits the search to a query service.
Query service hits fulltext index and gets 9,995 hits.  Creates a new stable
ID, "abcdefg123."  Caches this result, "abcdefg123"="{set of 9,995 hits}"
Resource consumes first 10 results from query service.  Sends something
like:
   
 abcdefg123
 9995
 1
 10
 The first of many
 ...
 The tenth of many
   
Let's say client wants the next page of results.  It immediately sends back:
   
 the 
 abcdefg123
 11
   
Resource asks query service for "abcdefg123" again.
Query service fetches "abcdefg123"="{set of 9,995 hits}" out of cache.
Resource consumes results 11-20 from query service ... etc.

Here, if a second user queries on "the" they would get their own guaranteed
stable result set, unless you can be really smart about knowing which result
sets are identical and can share an ID.

If the client waits too long before changing pages, and abcdefg123 goes out
of cache, the server can either return some sort of error, or repeat the
search and send back the response with some kind of flag to indicate that
the result set has changed.  (I like this last behavior, along with the
above "really smart about knowing which result sets are identical")

I like ehcache a lot for all this.  I can trivially implement memory
sensitive caches with disk backing to hold server side resources
representing result sets and other goodies.  This can be done very close to
the Representation level to avoid duplicative work, and the general usage
doesn't vary much between different kinds of data layers -- relational
queries, Web service queries, Lucene queries, XML document searches, etc.

Finally, if you're dealing with "dumb" HTML clients (that work page by page
and can't be bothered to keep state like what they queried for in the first
place), instead of the XML example above, you can incorporate a form that
repeats the search (with the appropriate pagination) directly into your HTML
result.  This isn't much of a problem with AJAX or desktop clients that can
maintain their own state better.

Any of that useful?

- R

On Fri, Jun 5, 2009 at 2:14 PM, Dustin N. Jenkins <
dustin.jenk...@nrc-cnrc.gc.ca> wrote:

> I'd like to be able to paginate my search results in my Restlet Web
> Application as the user can easily return hundreds of results.  I've
> searched around and came across the Value List Holder Design Pattern,
> but I'm not sure it meets my needs.
>

--
http://restlet.tig

Re: GSON

[Rob Heittman]

Cool recommendation!  "Packages to be usable under OSGi containers, as is."
 Ahh.
On Tue, May 19, 2009 at 1:34 PM, Tal Liron wrote:

> http://www.cowtowncoder.com/hatchery/jackson/
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2316325

Re: GSON

[Rob Heittman]

GSON is very nice.  It is lightweight and fast, simple and stable.  It's sad
for me that it depends on reflection, because most of my clients are
browsers, and it doesn't work in GWT.  Of course it's possible to manually
deserialize the object in raw Javascript or GWT, but this takes a lot of the
GSON goodness away.  If I was writing more services with Java on both sides
of the API, I would use GSON a lot more!
I'm excited about Jerome's work with serialized Restlet representations in a
GWT-compatible way.

On Tue, May 19, 2009 at 6:48 AM, Zsolt Czinkos  wrote:

> I'm just working on a very simple app on GAE, where I'm planning to
> use RESTLET + GSON + JQERY, so I would be very interested in your
> experiences, too.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2311896

Re: HttpClient Alternatives

[Rob Heittman]

Thanks, Bruno.  I was especially unaware that HttpClient 4.0 support had
been started already ... I'll check it out.  I wonder, too, if it mightn't
be possible to do something lighter based on HttpCore directly.
- Rob

On Wed, May 6, 2009 at 9:29 AM, Bruno Harbulot <
bruno.harbu...@manchester.ac.uk> wrote:

> Apache HttpClient 4.x support in Restlet:
>http://restlet.tigris.org/issues/show_bug.cgi?id=639
>
> Jetty Client:
>http://docs.codehaus.org/display/JETTY/Jetty+HTTP+Client
>
> Plans for a Grizzly Http Client:
>https://grizzly.dev.java.net/servlets/ReadMsg?list=dev&msgNo=2531
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2080871

HttpClient Alternatives

[Rob Heittman]

Hi all...

I think today I lost my last fight with HttpClient misbehavior...  
Failure to consume entity (not in my control) consumes a connection;  
subsequent attempts block ... This is a crummy failure mode.  I'm weary.

I'd like a Restlet client connector that provides the performance  
benefit of  simple http/1.1 persistent connections, but is more  
aligned with Restlet API, and maybe even could support a Restlet/GWT  
style async callback.

Anybody got the URL of a good alternative library to integrate ... Or  
should I just start with the Net client connector and go my own way?

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2074173

Re: errormessage, but correct url

[Rob Heittman]

It looks like you're not doing anything wrong ... time to look for server
bizarreness ... ?

If you have the ability to sniff outgoing headers (e.g. with wireshark) try
comparing the headers in your browser generated request versus your Restlet
generated request.  Sometimes a minor and insignificant difference can
expose a server side bug.
For example, last week I wasted a day tracking down a bug with a third party
web service that would return a similarly cryptic error when the
Content-Type header was "application/xml; charset=UTF-8" as opposed to just
"application/xml" ... service worked fine in some browsers, not in others.

- Rob

On Thu, Apr 30, 2009 at 2:15 PM, Jon Doe  wrote:

> Doesnt matter if I take this example or use the code in my application on
> the Tomcat server. I always get the following response:
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2000147

Re: GWT 1.6.4 (client only)

[Rob Heittman]

I have not updated to using GWT 1.6 routinely yet due to inertia issues, and
could really use a diff on the needed module XML changes etc. so I don't
have to self discover (hint hint).

The Restlet/GWT source needs to be on your classpath so that GWT can find it
for compilation.  The source itself can be bundled in a JAR or expanded in a
directory, but no matter how it gets there, the source needs to be on the
classpath -- as far as I know.  Or is there something new we can leverage in
1.6 to avoid recompilation of Restlet/GWT?

- Rob

On Thu, Apr 30, 2009 at 4:56 AM, Jerome Louvel wrote:

> Hi there,
>
> We haven't updated our Restlet/GWT edition to GWT 1.6.4 yet. This is
> however
> planned for later in Restlet 1.2 development cycle.
>
> If you can provide us with help for this update, like patches and guidance,
> that would save us time and make it happen earlier!
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
>
> -Message d'origine-
> De : webp...@tigris.org [mailto:webp...@tigris.org]
> Envoyé : mercredi 29 avril 2009 20:41
> À : discuss@restlet.tigris.org
> Objet : GWT 1.6.4 (client only)
>
> Hi,
>
> I have the org.restlet.gwt 1.2-SNAPSHOT and I'm using it only for the
> client
> capabilities, i.e. the server is in another project so I don't need the
> org.restlet.ext.gwt for the GWT Shell.
>
> The problem is that I have to build the jar with the source files because
> GWT complains that could not found the source for the restlet classes. I
> also have to modify the GWT.gwt.xml and remove all dependencies... seems
> that those modules don't exist in 1.6.4?? The correct dependencies I put in
> my own GWT module xml.
>
> The question is: Is org.restlet.gwt ready to use with GWT 1.6.4?
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=19836
> 74
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1993492
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1994710

Re: Finding the base reference for an application

[Rob Heittman]

Well, that's partly why I complicated the situation with a hostname change,
port change, and a URI prefix change (because the URI part I can't deal with
via the host header alone).
But -- assuming the only difference is the hostname -- it's a question of
who's doing the configuring of the creative proxy setup.  If the proxy admin
and server admin are the same person or can collaborate, then what you
describe is fine.   But here, couldn't I maybe just use IP forwarding/NAT,
and avoid proxying at all ... ?  If the proxy admin can't count on the
server admin to accept the external hostnames, then the proxy admin would
definitely want the host header rewritten to something the server would
understand internally.

For your EC2 node cluster can you just use a DNS round robin?  One nice
thing about RESTful services is that it typically doesn't matter a hoot
which node responds.  If you have a fairly dynamic DNS that can take a bad
(or under-maintenance) node out of rotation, that can do a good job for a
lot of simple cases.  I know vanishingly little about EC2 though ... don't
even know if nodes have discrete IPs  :-)

On Fri, Apr 24, 2009 at 8:57 PM, David Fogel  wrote:

> Hi Rob-
>
> Okay, I think I'm getting the idea of what you're using the proxy for.
>  But in the situation you describe of routing an external domain
> temporarily to some internal desktop server, couldn't you use virtual
> hosts to do the routing in the desktop, and use the original external
> domain?  i.e. couldn't you have, on your internal desktop, a virtual
> host set up for "demosomething.solertium.com"?  Why does the code need
> to know anything at all about
> "mydesktophost.internal.solertium.com:8182"?
>
> Sorry for all the grilling, but like I said, we've been trying to
> figure out a good architecture for deploying our restlet-osgi stuff on
> a cluster of amazon EC2 nodes, (and Amazon won't be coming out with
> their built-in load-balancing feature until later in the summmer-
> curses!), and so I'm in the midst of diving into networking sysadmin
> stuff that I know too little about...
>
> -Dave
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1900649
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1901113

Re: Finding the base reference for an application

[Rob Heittman]

Hey, I didn't write the darn things, no shoot the messenger  :-)  Still,
after a little research ... this all appears to be perfectly legal ...
RFC2616 13.5.2 lists the "end to end" headers that a transparent proxy is
not allowed to modify, and Host isn't on the list.
As I think about it though, both Host and other aspects of the resource
location are often mutated in the course of my more, er, creative ...
proxying.  For example, I can use Squid or mod_proxy (or Restlet
Redirector!) to proxy http://demosomething.solertium.com to
http://mydesktophost.internal.solertium.com:8182/demo ... here the proxy
needs to rewrite the Host as well as the resource URI, so my desktop
computer can figure out which of the umpty-odd services I'm currently
running to serve it with.  Great for this kind of demo/dev application.
 Performance is not a plus of the setup.
I think you are looking for more of a "content switch" which I don't think
is usually implemented as a true HTTP proxy ... like F5's BigIP products.
 Here -- based on my limited experience with BigIP -- requests are not
mutated and repeated, they are preserved transparently end-to-end as much as
possible, but selectively sent to the best available working node in a
cluster.  It's highly magical, and lovely if you can afford one.  Which, for
the record, I cannot.

Not that you can't use Squid or mod_proxy or whatever to front a cluster ...
we have a lot of clients who do this in their enterprise ... but typically
this works best for ordinary content traffic (GET html, jpg, etc.)  and
where the cost of generating that traffic far exceeds the cost of delivering
it.  So, if one has a cluster of poky AquaLogic portal servers that need to
spend a minute getting out of their own way to render a Web page (*),
putting a speedy and aggressively caching Squid in front of the mess can
effectively hide the ugly.  But I doubt it would improve upon your properly
constructed Restlet OSGi applications that ideally leverage the web(tm)  ;-)

John Mitchell should be along presently to straighten both of us out on this
subject.

It's Friday, I'm gonna go out and play.

- R

* anti JEE prejudice is showing

On Fri, Apr 24, 2009 at 6:38 PM, David Fogel  wrote:

> Hi Rob-
>
> I'm sure I'm just revealing my own ignorance about proxies here, but
> I'm wondering if you could go into greater detail regarding why
> reverse proxies would change the Host header.  Seems to me that the
> Host header is a fundamental part of the client's request, and is
> independent from IP-level network routing.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1899907

Re: Finding the base reference for an application

[Rob Heittman]

Every reverse proxy setup I know of changes the Host header (to
transparently hit the correct virtual host on the web server behind the
reverse proxy).  But they do also often pass along the original somewhere,
or can be configured to do so ... do you know which reverse proxy is in
play?  Squid?  Apache mod_proxy?

The duty to rewrite absolute URIs can be effectively laid on the proxy
itself; see http://apache.webthing.com/mod_proxy_html/ for some cool modules
that dynamically rewrite HTML, XHTML, and XML in the same fashion as Apache
ProxyPassReverse.  We use these at my office, where a bunch of dev machines
have historically lived behind an Apache reverse proxy to conserve IP
address space.

If the proxy can't do the job for you, I think you'll have to provide some
static configuration to map the external and internal hostnames, yucky
though that may be.

On Fri, Apr 24, 2009 at 5:20 PM, David Fogel  wrote:

> I'm not an expert in reverse proxies, but it doesn't seem reasonable
> for a proxy to change the Host header, or the requested path either.
> I wonder if it might be passing along the original in some other,
> custom header?
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1897989

Re: Restlet OSGi Services

[Rob Heittman]

Can you tell us more about what isn't working exactly?
Restlet is fine with dynamically adding and removing applications.  We do
this in our OSGi-based content management framework (gogoego.googlecode.com)
as a primary way of adding plugin functionality.  In our case, the plugin
bundle's Activator registers an Application factory with the content
management framework, which on a per-virtual-host basis may then choose to
bind these Applications to working routes.  It's a complex example, but it
works fine and the core behavior is pretty straightforward.
I'm guessing you are just missing a little bit of necessary glue.  Any code
or further details you can share?

On Fri, Apr 24, 2009 at 8:58 AM, Thomas Pham  wrote:

> Hi,
>
> I'm a little newbie with OSGi and Restlet, so my question is :
>
> I'd like to serve the creation of new applications/resources by other OSGi
> bundle when they are plug-in on the framework.
>
> I created a bundle named RestCore-Services that start the internal web
> server and provides a method (as a service for external bundles) to load
> dynamically new applications/resources provided by bundles.
>
> The webserver start but I can't add applications/resources.
>
> Does somebody try to this and can help me ?
> Or somebody have suggestions how to do that ?
>
> Thanks
>
> Thomas
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1891905
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1893616

Re: JSP/Servlet Representation

[Rob Heittman]

Thanks for the source!  I have a streamy variant someplace, but haven't
worked actively in the JEE world for a little while now, so have to go back
and do some repository archaeology to find it.
Jerome pushed back RFE 512 for a bit due to competing pressures, but still I
hope to work on it at some point, and it would be nice to scoop up RFE 753
at the same time.
On Fri, Apr 24, 2009 at 9:47 AM, Philippe Duchesne wrote:

> It's not published in any opensource project, but here is my code. It's
> really not optimized, as it doesn't even stream the data, but instead puts
> everything into memory. But you got the idea.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1893179

Re: JSP/Servlet Representation

[Rob Heittman]

Neat, Philippe ... is that BufferedServletResponseWrapper already
open-sourced anywhere?

On Thu, Apr 23, 2009 at 10:02 AM, Philippe Duchesne wrote:

> Hi all,
>
> i've faced a similar problem, so let me share how i solved it.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1880242

Re: How to Fetch Request XML in Java Restlet

[Rob Heittman]

This looks quite nice, good example!
2009/4/21 Jose Javier García Zornoza 


> I'll tell you what I'm doing, if somebody knows about a better aproach,
> please, tell something.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1859821

Re: How to invoke acceptRepresent in GET

[Rob Heittman]

I'd likely put the behavior that is the same into another method
("myInternalMethod(...)"), and call this method from both represent and
acceptRepresentation.  You aren't limited to only the methods required by
the class.
On Tue, Apr 21, 2009 at 7:38 PM, Rick  wrote:

>   Now I want to do the same stuff for GET operation as well. How can I do
> it without replicating this code which I wrote in acceptRepresent method? Is
> there any way I can just call accpetRepresent method in represent method so
> that GET operatiion can take care of it by re-using it?
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1859508

Re: "CRUD Items" pattern

[Rob Heittman]

Think John and I are in the same place.

> We have one resource at a URI like: /items ...
> It responds to PUT by creating a new item

Unless PUT is putting back the full representation of the list of items
(with some new items in it) this would seem like an unexpected REST
semantic; I generally expect PUT to mirror GET and vice versa.  POST works
here though.

/quibble

> However, it's somewhat inelegant, and the number of classes rises quickly
for complex applications.

Got a concrete example?  Usually I've found I can make one collection
Resource class work in an all-purpose way; item Resources may multiply
(usually in a polymorphic way) but I haven't often needed more than one
collection Resource to handle listing them ... maybe my applications aren't
complex enough  :-)

On Tue, Apr 21, 2009 at 3:28 PM, John D. Mitchell wrote:

> Howdy,
>
> On Apr 21, 2009, at 11:59 , Tal Liron wrote:
> [...]
> > The pattern would be very familiar to you, as it even appears in the
> > Restlet tutorials. I've been clumsily calling it "CRUD items." It
> > looks
> > like this:
> >
> > We have one resource at a URI like: /items
> >
> > It responds to GET with a list of all items (possibly filtered by
> > attributes)
>
> If there can be lots of items,  you'll want to decide on a limit to
> return in any one response and "paging" so you can iterate through all
> of the items list.
>
> > It responds to PUT by creating a new item
>
> That should be "POST".
>
> > It responds to DELETE by deleting all items
>
> I presume you have some appropriate authority control in place for
> that. :-)
>
> > We have another resource at a URI like: /item/{id}
> >
> > It responds to GET with that specific item
> >
> > It responds to POST by updating that item
> > It responds to PUT by replacing that item
>
> What does that mean?  I.e., they are probably the exact same code
> (unless you allow POST to "update" only some fields but require PUT to
> set all fields)?
>
> > It responds to DELETE by deleting that item
> >
> >
> > Now, this pattern is very easy to implement in Restlet by using two
> > classes extended from Resource (or ServerResource), and then attaching
> > both to the Router. However, it's somewhat inelegant, and the number
> > of
> > classes rises quickly for complex applications. It seems to me that
> > there's room for simplification. But I can't think of a
> > straightforward
> > way to do this, because of the way Restlet encapsulates resources.
>
> Um, er, actually there's no real reason for them not to be implemented
> using a single "Resource" sub-class.  I've done this and it keeps
> things pretty nicely manageable.
>
> > One of my thoughts was that I could put the functionality of both
> > into a
> > single Resource class, and perhaps switch according to the
> > ResourceRef.
> > This quickly, though, gets very complicated, especially due to the
> > handling of negotiation/conditional modes. It seems to be pushing the
> > Resource class into directions it wasn't intended to support.
>
> Can you be more specific about the problems your having?  I've done
> this using the Restlet v1.0.x code base and have content negotiation,
> etc.
>
> Thanks,
> John
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1847582
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1847702

Re: Distributed Observer Pattern

[Rob Heittman]

So, in case people don't actually click the link, let me repeat from the
article:
"this only applies where the feed consumer is a visible and POSTable server
... and probably where the number of subscribers is relatively small
... This isn't done now simply because of the asymmetry of the current Web,
an asymmetry which we are free of in REST [server-to-server] integration."

Okay, so given all that is true and this pattern fits the use case.  The
Resource object in Restlet (ServerResource in Restlet 1.2) only transiently
exposes an underlying physical resource -- e.g. a file, a row in a database,
etc. -- for the purposes of serving a request.  None of the core Resource
behavior needs to change in relation to serving a GET of whatever the
underlying object type is, when you use this pattern.  But you do need to
detect the presence of the magic header and provide that information to
whatever service is sending the POST change notifications in the future.
 The Resource itself needn't offer this service, and probably can't and
shouldn't.  I think it would be better handled centrally by a long-lived
facility that can manage the issues of how many notifications to send
concurrently, how to deal with backlogs, duplicate observer registrations,
etc.

Probably this is some kind of separately threaded client notification
engine, maybe using Restlet's Client features, and it almost certainly needs
APIs like

  notificationEngine.addObserver(String resourceIdentifier, String
urlToNotify)
  notificationEngine.notifyObservers(String resourceIdentifier)

The only extra behavior in the Resource would call
notificationEngine.addObserver upon a GET.  notifyObservers would clear out
each observer as it is called to satisfy the pattern.  The storage of who is
notified about what ends up in the notification engine (a purely server side
concept not exposed as a REST resource), which can just be in memory,
persisted to disk, put in a database, whatever your application requires for
other reasons.

On Mon, Apr 20, 2009 at 11:03 AM, Jurrie Overgoor  wrote:

> Hello everyone,
>
> I'd like to implement something based on the Distributed Observer Pattern
> as described by Duncan Cragg on
> http://duncan-cragg.org/blog/post/distributed-observer-pattern-rest-dialogues/
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1839105

Re: Scripted Restlet - Demo Distribution

[Rob Heittman]

Sorry I was not able to reply to this yesterday ... the airlines were
conspiring against me.  Thanks for the clarification, Jerome, I wasn't sure
what kind of feedback to give.
Personally, I also think that making this the "Scripturian" extension is the
way to go.  Tal, I hear you about the "accidental brand" thing ... but then
again I think that's how most of the great open source brands have emerged,
so maybe just roll with it  :-)  I think that giving this a name as A Thing
In Itself gives you the maximum flexibility to push the limits of what can
be done without having to worry that everyone agrees to it as canon and that
it meets all needs.  It also frees those of us who are working in both
Restlet and script from feeling an actual obligation to track it and
encourages us to track it for good reasons.

There's a lot of exciting Restlet power being extended to a lot of different
languages by this facility, and it seems like a great outreach to developers
doing serious web service development in JVM-hosted script languages.  It's
also a big undertaking; my perspective has been that these are very distinct
communities and they all have different needs.

Our approach in GoGoEgo (and use for scripting) has been different and
intentionally quite limited.  The framework is set up to encourage writing
intensive functionality in compiled languages like Java or Scala, limiting
the use of script to lightweight in-page purposes.  This has to do with
reflecting a separation of abilities and responsibilities we typically see
in commercial Web projects.  So our design has been to treat scripting at
the representation level (and only in decorated HTML) and not a resource
level, and there is a very narrow and administrator-controlled band of
context made available to each script by plugins.

But our Representation based approach doesn't do very much for, say, a
serious Groovy developer who wants to *write* such plugins -- in fact it
badly gets in their way.  So I think there may be a reasonable path to allow
Scripturian to be plugged into GoGoEgo to enable the deeper stuff -- support
of Resources and other intensive work written in scripting languages, which
then are exposed in a controlled way using the content management framework.
 Following some experimentation by Carl Scott and I this week, we will
probably add a "support Scripturian extension" RFE on the GoGoEgo side tied
to a "support Restlet 1.2" RFE ... currently we are using 1.2M1 due to a lot
of flex in the Restlet trunk post M1.  That exercise may produce some actual
useful feedback, but here's a forecast:

The main obstacles I foresee will have everything to do with packaging and
our full-bore adoption of OSGi ... but I know Tal has been thinking of OSGi
issues as well.

The other friction point is what to do about two different systems trying to
use embedded scripts.  In present form it would not be any issue, as we
trigger on e.g. 

discuss@restlet.tigris.org

[Rob Heittman]

In the REST architectural style, each request/response cycle is stateless,
which implies that each request carries all the information necessary to
service it; this includes any needed authentication credentials.

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

Since HTTP uses the REST architectural style, this is implicit in HTTP as
Stephan says.  So any HTTP authentication mechanism (Basic, Digest, etc.)
sends the credentials with every request.  In session style applications,
usually a cookie is used for authentication of each request -- that is, to
associate each stateless HTTP request with a particular session on the
server.  Whether the information is sent in the Cookie: header or the
Authorization: header, the information is present in every request.  The
same applies to authentication with SSL Certificates or other HTTP schemes;
the authentication information is in every request.

You can pick any of these systems under Restlet to authenticate requests.
 The Security API work that has gone on in Restlet 1.2 introduces good and
complete mechanisms for working with every popular authentication scheme I
know of, but you don't need Restlet 1.2 to write your own Guards or Filters
that look at cookies or any other type of credential.

HTTP Basic is a good choice for many applications because it is so simple.
 It is well understood by developers and widely supported by clients, and
easy to implement.  Its performance is also very good.  Its main drawback is
that the password is essentially sent in the clear.  So, if used over the
public Internet, HTTP Basic must be armored in SSL.  If your entire server
side application is not fully trusted, this is also a problem since all
parts of your server application can reconstruct users' actual passwords by
interrogating the HTTP headers.  If either of these problems is a blocker
for your application, it would be best to pick a mechanism other than HTTP
Basic.

- Rob

On Wed, Apr 15, 2009 at 12:25 PM, fgr81  wrote:

> Hi stephank,
> I refer to first case, because I'm doing an application where the user
> interacts often with his data. For now, I know only HTTP_BASIC.
> Thank you for the answer...
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1729510
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1730832

Re: Google AppEngine and Restlet

[Rob Heittman]

Awesome work, Jerome, and very quick turnaround!  Off the top of your head,
does RIAP work in the App Engine port?

On Sat, Apr 11, 2009 at 9:42 AM, Jerome Louvel wrote:

> Here is our official announce:
>
> http://blog.noelios.com/2009/04/11/restlet-in-the-cloud-with-google-app-engi
> ne/
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1649420

Re: Annotations and Restlet's future

[Rob Heittman]

GWT 1.5/1.6 is happy with annotations at compile time ... but if the
implementation needs to examine them at runtime via reflection, GWT doesn't
have that capability.  GWT getClass() emulation doesn't have
getAnnotations() ... or much of anything else.  There's no reflection in the
Javascript room.

Restlet 1.2's current incarnation is fine with me ... annotations optional.
But I agree that the non-annotation and annotation approach should use the
same vowels and consonants in the same order whenever possible  :-)  This
helps us bears of very little brain.

On Thu, Apr 9, 2009 at 7:06 AM, Tim Peierls  wrote:

> On Thu, Apr 9, 2009 at 4:57 AM, Rob Heittman 
> wrote:
>
>> ...my only *strong* requirement, that the annotation based solution must
>> remain a voluntary choice and not the only way to get things done.  It
>> should remain possible to achieve whatever annotations can achieve in a
>> non-annotation way.  This allows the basic API outline to work in places
>> where annotations are not available or work differently enough to cause
>> friction (pre-1.5 JVM backports, GWT, API ports to other languages, Scala
>> ...)  It is OK with me if the non-annotation approach requires verbosity or
>> heavy lifting, it just needs to exist.
>>
>
> Isn't that currently the case with the 1.2 branch? (Does GWT not support
> annotations yet? I thought it did.)
>
> It would be best if the non-annotation approach used the same terminology
> as the annotations, and I think that's not the case right now.
>
> --tim
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1618441

Re: Annotations and Restlet's future

[Rob Heittman]

Good treatment, Dave, not too long  :-)

I do agree with your thoughts generally ... except to harp on my only
*strong* requirement, that the annotation based solution must remain a
voluntary choice and not the only way to get things done.  It should remain
possible to achieve whatever annotations can achieve in a non-annotation
way.  This allows the basic API outline to work in places where annotations
are not available or work differently enough to cause friction (pre-1.5 JVM
backports, GWT, API ports to other languages, Scala ...)  It is OK with me
if the non-annotation approach requires verbosity or heavy lifting, it just
needs to exist.

I can indeed see the benefit of writing many Resources more economically and
intelligently with the right annotations ... and I also think, used
consistently, this could help with my little dream of producing a machine
and human readable REST interface specification that gives a large chunk of
the enterprise value of WADL and WSDL without any of the associated misery.


> So, to sum up what has been a much-too-long post, I'm convinced that
> it's desireable to attempt to replace the unavoidable writing of
> routing code with annotations on target methods, as long as the
> annotations are clear, self-explanatory, and don't try to hide too
> much magic.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1611242

Re: Annotations and Restlet's future

[Rob Heittman]

JAX-RS = JSR 311.  JAX-RS is available as a Restlet extension.
I'll point out one elephant in the room, though: the JAX-RS extension has
not yet received the same level of attention as other Restlet extensions
that were developed by the core Noelios team.  Even the Restlet-GWT
extension I lead was mainly ported by Jerome ... I just helped over
implementation hurdles and provided concrete use cases and documentation.
 Anyway.  The JAX-RS extension doesn't feel as "finished" as the core of the
project, because it's not.  This probably ain't right.

Also: JAX-RS feels a lot to me like JPA.  I can mark up any old POJO with
annotations that brilliantly, even miraculously generate glue for a
particular paradigm (REST or relational persistence).  But, to me, either
one still amounts to a very lovely, silver filigreed, impeccably wrought
glue gun.

If I'm writing RESTful web services, I want a thoroughly RESTful
architecture surrounding me, dammit ... which is what Restlet provides.  I
want my Resources to know all about it and leverage it to the hilt.  They
are where the rubber meets the road; where the underlying system is modeled
in a RESTful way.

So I'm kind of like Lars here, a conscientious annotation objector  :-)  But
I also think I see what Jerome is doing too -- providing annotations that
aren't meant to be a generalized glue gun, but a way to straightforwardly
tell Restlet things that might take a lot of boilerplate to do otherwise.
 This is a neat idea.  It seems like it's not meant to be a generic "RESTify
your POJO" mechanism -- which JAX-RS already is -- but a way to author
Restlet Resources with less effort and perhaps even less pratfalls.  I
haven't played with it enough to know whether it fills that role effectively
... I may not get a chance before it's too late to really comment.

The broader concern I have ...  well, I vainly think I see the point of the
new Resource annotations because I have become a hard core Restlet
developer.  Still, what does a newbie think?  It's confusing to have two
slightly different annotation systems in play at once.  It looks like
Restlet is taking on JAX-RS with an alternative, and the user must choose
one.  The message traffic seems to reflect this confusion is already
happening.  I think having a Restlet @Get("form") and a JAX-RS @GET is
probably more confusion than a lot of folks can swallow.

Hibernate seems to have played it well by heavily internalizing the JPA
spec, using JPA where it fits, and providing custom annotations where it
doesn't.  Maybe wrapping JAX-RS in a tighter embrace and making it more core
to Restlet is part of the solution.

Or, to solve the confusion, it may be as simple as modulating the annotation
names.  I don't know:  @ResourceGets("form") instead of @Get("form") or
such.  This would make clear that it's a Restlet thing and not an abstract
standards-driven RESTful markup thing.

Anyway ... my personal preference is to leave the darned things out
entirely, so perhaps I oughtn't to be operating my keyboard to comment on
this.  I only like to use annotations for purely compile-time code
management purposes (@ThreadSafe, @SuppressWarnings) and not really ever for
functional purposes.  Pass the boilerplate and a side of fries.

- Rob

On Wed, Apr 8, 2009 at 7:35 PM, Erik Beeson  wrote:

> Jerome was on the JSR 311 expert group but Restlet doesn't support it?
> --Erik
>
>
> 2009/4/8 Rémi Dewitte 
>
>> I can see that Jérôme has already answered a great deal of my questions in
>> this thread :)
>>
>>
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1596334
>>
>> Rémi
>>
>> 2009/4/8 Rémi Dewitte 
>>
>> Hello,
>>>
>>> I struggle to get convinced to the use of annotations for resources from
>>> all I can read from various threads.
>>>
>>> I have the feeling to lose most of the reasons to use Java. MediaTypes
>>> are strings, I find the implementation a bit tricky with reflection forced
>>> to be cached to be fast, classloaders issues. I guess there is a rule to
>>> handle annotations with class hierarchies, etc.
>>>
>>> I totally understand that some people like annotations and the work it
>>> has triggered was a good way to get the resource API even better.
>>>
>>> What are the benefits of using annotations with Restlet ?
>>> Restlet annotations are a competitor of JAXRS, right ? To what extend is
>>> it better ?
>>> Will annotations in restlet the "advertised" way of creating restlet
>>> application ?
>>> What are the other planned uses of annotations ?
>>>
>>> Regards,
>>> Rémi
>>>
>>
>>
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1604945

Re: Google AppEngine and Restlet

[Rob Heittman]

:: smiling ::  Gosh, it's been available all day ... I'm sure someone has
tried it out by now ...
We'll be experimenting with it heavily between now and Google I/O at end of
May -- we already have a "lite" version of our Restlet-based GoGoEgo CMS
engine that runs on the Python version of App Engine, and will be seeing
what better stuff can be done with the Java version.

If Restlet doesn't run well on the Java version of App Engine out of the
box, I'm sure some of my team will want to work on portage ...  :-)

- R

On Wed, Apr 8, 2009 at 3:23 PM, Lars Heuer  wrote:

> Hi all,
>
> Just out of curiosity: Has someone tried Google AppEngine [1] together
> with Restlet (Servlet connector)?
>
> [1]
> 
>
> Best regards,
> Lars
> --
> http://www.semagia.com
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1601014
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1601077

Re: Annotations and Restlet's future

[Rob Heittman]

I would agree with that as a guide (and I think it is what Jerome has in
mind) ... the annotations are nice for people who like them.  It seems
Jerome is striving for something very terse that supplants boilerplate in a
number of common cases, which I can see is a nice goal.  But if annotations
were ever *required* to get things done, it would cause some real problems
for me.
On Wed, Apr 8, 2009 at 2:58 PM, Lars Heuer  wrote:

> I moved to Restlet 1.2 M2/snapshot without using annotations. I found
> no reason why these annotations will help me. Everything works fine
> without annotations and I think/hope Restlet won't force us to use
> them in the near future.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1601018

Re: DirectoryResource throws/logs useless exceptions for CLAP protocol

[Rob Heittman]

I also wish it were a bit faster.  We do serve several hundred thousand
impressions out of Directory every month, but we serve several million using
thinner Resources not wrapped in Directory -- not sure what would happen if
we wrapped those in Directory.

On Tue, Apr 7, 2009 at 1:58 AM, David Fogel  wrote:

> The Directory class is the only built-in way for plain, non-servlet,
> Restlet apps to serve static content.  Should we consider it
> "production"-ready w.r.t. performance  under load?  Another way of
> asking this: is the Directory class a reasonable substitute for, e.g.
> Jetty's DefaultServlet?
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1576580

Re: ServerResource is currently incompatible with OSGi

[Rob Heittman]

There's a lot of precedent -- look at all the weird stuff that ends up in
System.properties() on startup of some JVMs, or the values hanging out in
ServletContext or PageContext in every JEE server I know.  Doesn't mean it
thrills me.
Thanks for spotting this, David ... would have been a stopper for me as
well.

I agree Tal's short term solution should work with minimal changes to the
implementation.

On Tue, Apr 7, 2009 at 2:51 AM, David Fogel  wrote:

> Yet the Context, as a very
> prominent and unavoidable part of the Restlet public API is meant to
> be used and understood.  That's why I think it isn't a good place to
> stash implementation-related data like this annotation stuff.
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1576284

Re: Redirector: HTTP request to HTTPS request

[Rob Heittman]

Anecdotally ... I proxy from http to https all the time using Redirector ...
the masking to an empty 200 status looks like that perennial Tomcat 5 issue
with no-entity responses.

On Thu, Apr 2, 2009 at 3:32 PM, Jerome Louvel wrote:

> Hi Matt,
>
> Were you able to solve this? If not, could you enter a defect report and
> attach your test case?
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1523369

Re: list of resource with relatives url

[Rob Heittman]

Excellent summary, Stephen!  Requiring a descriptor (in any format) to find
a service URI often just moves the problem -- making the next question "what
is the best URI to publish the descriptor?"
Still, it's needful to describe REST APIs, and this often seems unreasonably
hard to do.  For me, anyway.

Someday I'd like to attack a Restlet-specific application descriptor
mechanism that is both machine and human readable ... sort of an extended
Javadoc for Restlet ... I think the Resource refactoring might be one key to
doing this.  Ideally the descriptor would work two ways -- you could export
it from a Restlet server application, and then feed it to a code generator
to make a Restlet client skeleton.  We'd also need some way of interrogating
the "plumbing" of an application -- what patterns reach what targets.
 Anyway, fun to think about.

- Rob

On Thu, Apr 2, 2009 at 2:26 PM, Stephen Groucutt  wrote:

> I guess this is a long way to say "I don't know", but I also think that in
> a proper REST design, it probably doesn't much matter.  :)  In my opinion,
> you can either codify the endpoints formally, as in a WADL, or you can
> informally simply agree on your starting point URIs, code them into your
> clients, and go from there.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1522571

Re: CSS and HTTPS problem ...

[Rob Heittman]

You'd have to change the CSS to also reference the images, etc. over https.
 The warning you describe will be triggered whenever you have an HTML page,
delivered over https, that calls images, CSS, or javascript from another
source, delivered over http.  This isn't a Restlet thing ... it applies to
any SSL Web server.
However, one neat Restlet thing that does help, is the Redirector feature.
 This is a bit advanced, but you can use the Redirector on your local web
service to proxy these requests to the other server; this can be used to
avoid such warnings and single-source issues, at the expense of some
overhead in your web service and a responsibility to manage the security
appropriately.

- Rob

On Tue, Mar 31, 2009 at 5:34 AM, Mohamed Abdel-Aziz Bayoumi <
mohamed@gmail.com> wrote:

> Hi Rob,
>
> Thanx for the fast reply ... As it told you Rob i'm using absolute links to
> images or css (since these are not hosted on my server) like the following
> CSS snippet (the background property)
>thead th,tbody th
>{
>   background : #FFF url(
> http://muffinresearch.co.uk/code/xhtmlandcss/tableshow/th_bck.gif)
> repeat-x;
>   color: white;
>   padding : 5px 10px;
>   border-left : 1px solid #CCC;
>   }
> another important note: i've switched to HTTP instead of HTTPS just to test
> and the style was displayed perfectly (no broken images or missing css
> files) both locally and remotely (i didn't change anything in code) which
> makes me 100% that the problem is mainly considered with HTTPS connection as
> i told you before ...
>
> Thank you
>
>
> Hard to diagnose without seeing the HTML source ... but is it possible your
> HTML is constructed with an absolute URL (starting with http://) in the
> CSS
>  tag?  Any snippets of the HTML you can share, or a link to a
> page if it's public?
>
> On Fri, Mar 27, 2009 at 10:46 AM, Mohamed Abdel-Aziz Bayoumi <
> mohamed@gmail.com> wrote:
>
> > It's been a long time since i posted here ... hope u r all fine n well ..
> > Now my problem.  I've planned to add some style to one of my restlet
> (which
> > is actually a TEXT_HTML MediaType repreaentation) so i made an external
> > stylesheet n saved my .css file and linked it to my html restlet and
> began
> > to test n here u r what i found (note: i'm running the whole application
> via
> > secured HTTPS):
> >
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1445199
>
>
> --
> View this message in context:
> http://n2.nabble.com/CSS-and-HTTPS-problem-...-tp2544622p2562022.html
> Sent from the Restlet Discuss mailing list archive at Nabble.com.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1493998
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1498463

Re: CSS and HTTPS problem ...

[Rob Heittman]

Hard to diagnose without seeing the HTML source ... but is it possible your
HTML is constructed with an absolute URL (starting with http://) in the CSS
 tag?  Any snippets of the HTML you can share, or a link to a
page if it's public?

On Fri, Mar 27, 2009 at 10:46 AM, Mohamed Abdel-Aziz Bayoumi <
mohamed@gmail.com> wrote:

> It's been a long time since i posted here ... hope u r all fine n well ..
> Now my problem.  I've planned to add some style to one of my restlet (which
> is actually a TEXT_HTML MediaType repreaentation) so i made an external
> stylesheet n saved my .css file and linked it to my html restlet and began
> to test n here u r what i found (note: i'm running the whole application via
> secured HTTPS):
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1445199

Re: Resource factories

[Rob Heittman]

In addition to what Rhett said ... one massively huge benefit of
having Resources that are created per-request is that they need not be
thread safe.  Very few developers (:: cough :: except Tim) can do
concurrency correctly every time.

But I've spent most of the afternoon noodling over this discussion and
wondering why the Resource construction issue has never really bugged
me like it bugs Tal.  I guess I just have never written Resources that
have a lot of of local configuration state.  This might be because I'm
not an IoC/DI guy by default -- it's a tool I use sometimes, but not a
fundamental way of thinking for me.

It may also help to know that I tend to like functional programming a
lot, and tend to avoid static fields in general; I fear the bite of
class loader hierarchies I didn't expect.  For the higher-level
configuration stuff, I tend to dynamically fetch it from the
Application itself (which of course is wired-in and long-lived) or the
Context.  Really, this isn't noticeably costly.

I'm not in opposition to more ways of constructing a Resource.  But I
also feel, somewhere in my bones, that if Resources really chafe at
the existing model, they /probably/ can be refactored or redesigned to
be a much smoother fit, without losing anything important ... but just
thinking differently.  I would be willing to have a look at a concrete
case -- e.g. a resource in the scripting extension -- and try to make
a proposal if one fits.  Then we could talk about it in code review
specifics and not in general architectural chalk talk.

- R

On Mon, Mar 23, 2009 at 4:08 PM, David Bordoley  wrote:
> Out of curiosity is there a reason why Resource isn't implemented as a
> subclass of Restlet? It seams like there is a lot of overhead in
> initializing a new Resource on every request especially when a lot of
> salient features such as what methods,variants, etc that are supported
> tend to static for a give route to that resource.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1394971

Re: Resource factories

[Rob Heittman]

I'd be careful of judgement-words like "bad practices" since this implies
some universal level of harm in all cases.  I think the current Finder
design is simplistic, flexible, and easy to implement.  I think there is
also room for a more structured base implementation that exposes some
advantages for more complex resource object hierarchies.  I don't think
these are mutually exclusive.

On Mon, Mar 23, 2009 at 2:34 PM, Tal Liron wrote:

>  Good point, Rhett.
>
>
>  Well, let me put it this way -- do you think the current Finder design
> encourages bad practices for Restlet users?
>
>
>  -Tal
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1391583

Re: Benchmark - Restlet 1.1.3

[Rob Heittman]

I don't have pretty graphs and charts, but here are my observations ...

The low level API (the Restlet class and friends) is not materially
different from low level code written for Servlet.  When I looked at
this long ago (Restlet 1.0), I could not tell any externally
detectable performance difference between a Hello World Restlet and a
Hello World Servlet running on the same machine under the same Tomcat
6 instance.  I also tested a non-trivial WebDAV Servlet vs. a Restlet
port and did not observe any performance difference.

Now for the interesting part.  When I optimized the Restlet WebDAV
version to use the high level Resource API and less hand written
stuff, the performance *increased* a tiny fraction -- 3% or so in
requests served per second.  And from a user perspective, the
performance increased *much* more, because it now properly handled
conditional GETs and other operations that my original code did not
(and the JMeter based test harness did not test).  This made people
using the WebDAV layer feel a lot better liveness in their requests
and snappier performance in Explorer or Finder.

This general observation has borne out as we've moved apps to Restlet.
 The app doesn't slow down any if we just glue our old code under
Restlet ... and the application performs drastically better when we
use Restlet well.

On Fri, Mar 20, 2009 at 12:27 PM, David Fogel  wrote:
> One of our questions in choosing to build our technology stack on top
> of Restlet is that we're not sure what the additional overhead is,
> given that Restlet adds some layers on top of, for instance, Jetty or
> Simple.  To put it another way: what is the price in performance that
> we need to pay for a better more RESTful API?

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1366010

Restlet @ Google I/O

[Rob Heittman]

Hi all,

I was wondering if anyone else from the Restlet list was planning to
attend Google I/O at the Moscone Center in San Francisco, May 27-28.
(http://code.google.com/events/io/)  ...  or just was living nearby,
or planning to be in the Bay Area around those dates.

There is a bar walking distance from the Moscone Center, the Thirsty
Bear (http://www.thirstybear.com).  During the dot-com boom, the
marketing gurus at my old company strategically invested a lot of
capital to rent out the place (see the commemorative t-shirt:
http://www.solertium.com/downloads/thirstybear.jpg)

My little team sure can't rent out the whole place, but we can indeed
buy a beer for Restleteers attending I/O.  If you're going to be in
the area, give me a shout directly: rob.heitt...@solertium.com  ...
and let's get together for a brew (or your choice of good Spanish
cuisine) and talk about Restlet and other fun stuff in May.

- Rob

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1360627

Re: Re: Hidden cache in GWT client?

[Rob Heittman]

You must use the non-standard header updating mechanism to manipulate
Cache-Control:

Form headers = (Form) response.getAttributes().get("org.restlet.http.headers");
if (headers == null) {
  headers = new Form();
  response.getAttributes().put("org.restlet.http.headers", headers);
}
headers.add("Cache-Control", "no-cache");

This mechanism works fine, but it's kind of verbose -- and you get a
warning from Restlet 1.1, which you can ignore.  There isn't an easy
message.setCacheControl(CacheControl.NO_CACHE) or some such method
built into Restlet yet.

- Rob

On Thu, Mar 19, 2009 at 11:54 AM, martin  wrote:
>
> Hi Rob,
>
> Thanks for your remarks!
>
> I tried to add an attribute "Cache-Control" with value "no-cache" both on the 
> server response and the client request:
>
> // Server
>
> Restlet situation = new Restlet() {
> �...@override
>  public void handle(Request request, Response response) {
>  ...
>  response.setEntity(kml,MediaType.TEXT_XML);
>  Map map = new HashMap();
>  map.put("Cache-Control", "no-store");
>  response.setAttributes(map);
>  }
> };
>
>
> // Client
> ...
> request.setAttributes(map);
>
> But nothing changed!
>
> Please note that I only encountered this problem when running the GWT client 
> from hosted mode. When I browse the same URI through the Firefox navbar, I 
> have no caching problem, and the appropriate document version is displayed.
>
> By the way, what do you mean by "caching is not good in 1.1"? I am actually 
> using this version of restlet and would like to avoid changing version right 
> now :)
>
> Martin

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1356387

Re: Hidden cache in GWT client?

[Rob Heittman]

Hi Martin,
Underneath it all, GWT is using the XmlHttpRequest facility of the browser
as a client.  For GET requests, this is influenced by the caching-related
response information your server resource exposes.  Different browsers have
different rules about how aggressive to be.  Caching-related headers include
"Cache-control," and "Expires."  The ETag header exposed for a resource is
also used by most current browsers to do conditional GET operations in the
future; these may hit your resource and get a 304 Not Modified response.

If you do not ever want clients to cache the representation they GET (and
this goes not just for GWT or XmlHttpRequest, but all user agents
generally), the easiest thing to do is to send a Cache-Control: no-cache
header.

Have a look at this thread for more information and references on
influencing client-side caching and how browsers treat it.

http://www.mail-archive.com/discuss@restlet.tigris.org/msg06759.html

Restlet's support for influencing caching is not good in 1.1, but some work
on this is underway in 1.2.

- Rob


On Thu, Mar 19, 2009 at 9:43 AM, martin  wrote:

> Hello all,
>
> I have used a GWT restlet client into an existing GWT application with
> success.
>
> My problem is that when I try to access a server resource several times,
> the client actually calls the server only one time!
>
> Let's be -a bit- more precise with the following piece of code:
>
> client.get(uri, new Callback() {
>  public void onEvent(Request request, Response response) {
>   ...
>  }
> );
>
> 1) calling response.getStatus().isError() returns false...
> 2) but calling response.getEntity().getText() allways returns what was
> provided at the first GET request.
>
> On the server side, the Restlet.handle(Request request, Response response)
> is called at the first GET request, and is never called latter.
>
> I tried looking at GWT client code without finding any caching system. May
> that be possible that some default GWT settings infer with the GWT restlet
> client library?
>
> Thanks in advance!
>
> Martin
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1355533
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1355684