Hey, isn't semantic inadmissibility the basis for thought crimes and fundamentalism? :)
I want to thank you Rob for the detailed answer, I get your point about the higher abstraction level giving you more freedom from the implementation. That's definitively a good thing. When you say "callbacks", what do you have in mind? Something like Comet? Cheers Jaime On Feb 5, 2008 3:37 AM, Rob Heittman <[EMAIL PROTECTED]> wrote: > > As a third party kibitzer ... I feel like saying "Restlet vs. Servlet" at > all is a bit semantically inadmissible. It's not an "or" operation. You > can run Restlet with, without, in, outside, talking to, or being talked to > by Servlet. The scope of the javax.servlet API is intentionally narrower; > all it does is model REST-style Uniform message passing > (service(request,response)) for the purpose of writing server code. > > The Restlet framework adds a whole new abstraction layer specifically for > modeling REST applications. With this, much or most application work can be > done with higher-level Representations that are separated nicely from the > service(request, response) paradigm. Both client and server can interact > with the same Representation objects -- and indeed the same Uniform message > layer -- whether or not any Servlets are involved in the process. > > On the "I/O agnostic" topic specifically, this separation of concerns > becomes very interesting now as we explore things like asynchronous > processing in the Restlet API. We can add mechanisms for things like > callbacks -- things not even remotely modeled in the Servlet API -- that > affect the message passing aspects in dramatic ways, without > Representations, or in many cases even Resources, having to be aware of the > change. > > NIO can make an HTTP connector more scalable at dispatching calls to > Servlets -- obviously both Restlet and Servlet run on top of Jetty, MINA, > and Grizzly NIO connectors, to name a few -- but the Servlet API does not do > anything particularly interesting to expose non-blocking/asynchronous design > advantages. If it did/when it does, Servlet authors will need to do > refactoring to take advantage of it. With a more separated API like > Restlet, it is easier for major design revolutions to take place in the I/O > layer -- pluggably and optionally -- while the bulk of the application > remains stable. > > At my company, before we discovered Restlet, we wrote a lot of this SoC > ourselves -- trivial Servlets that interacted with Resource and > Representation objects -- but our code was pretty much tied to J2EE > containers, because there was just too much plumbing in Servlet that we > didn't want to re-create in a more abstract way. After porting this all to > Restlet, we find ourselves able to run the same applications online, > offline, with or without a J2EE container, and have a nascent ability to do > so in transcoded environments like GWT. I feel sometimes like we need to > get Duke out of retirement to hop around and say "Write Once, Run Anywhere > ..." That is really how it feels. > > - R > > > > On 2/5/08, jbarciela jbarciela <[EMAIL PROTECTED]> wrote: > > Now, are you saying there that there is something conceptual that > > prevents Servlets to use NIO? (apart from possible implementation > > details in particular servers like Tomcat) > > If that's true, then how should we interpret statements like "Jetty > > can use NIO" or "Glassfish can use NIO" ? > > > > Please notice that I don't intend to start a confrontation of the "I > > say they say" kind, only looking for enlihgtment > > > >
