Sounds like a worthy goal. Please test it a lot against real world code so we can tell all the things that break.
On Mon, Jul 27, 2009 at 12:32 AM, marius d. <marius.dan...@gmail.com> wrote: > > I created wip-marius-http-abstractions branch and commits will follow > soon. I started the approach of decoupling Lift from HttpServletXXX > references and work with our traits HttpRequest, HttpResponse, > HttpServiceProvider etc. When Lift runs in a JEE web container the > implementation of HttpServiceProvider will sit on top of the existent > Filter approach. > > I am aware that this would lead to some breaking changes but only if > the application is directly using HttpServletRequest ... but typically > I've seen that people use S.xxx functions so there probably won't be a > significant breaking change. Nonetheless let's see how this shapes > out. My goal here would be: > > 1. Abstract JEE references in Lift > 2. Add support for AsyncWeb > > Br's, > Marius > > On Jul 26, 10:54 am, "marius d." <marius.dan...@gmail.com> wrote: > > Looks like AsyncWeb model is pretty straight forward for sending down > > async responses. It doesn't have suspend/resume but we can create a > > Response object out of the request and from any thread call > > commitResponse. With this model Comet should work correctly just fine. > > Looks like currently AsyncWeb site has some problems and I can't > > download it ... bummer ... next week then :) > > > > Br's, > > Marius > > > > On Jul 25, 9:33 pm, "marius d." <marius.dan...@gmail.com> wrote: > > > > > On Jul 25, 9:25 pm, Timothy Perrett <timo...@getintheloop.eu> wrote: > > > > > > Hey Marius, > > > > > > I read your email with interest - myself and viktor were only today > > > > discussing all the various technologies such as this which are now > flooding > > > > the wider JEE eco-system and how lift can interoperate with them (or > if > > > > indeed we need to / should) > > > > > > I think perhaps there is something wider to consider here: possibly > abstract > > > > things away so pluging lift into something other than HttpServlet is > fairly > > > > straight forward. You talk below about AsyncWeb, but it seems the > same might > > > > be true for the Grizzly NIO family of projects? > > > > > Most definitely ... my goal would be to be HTTP "platform" agnostic. > > > If the platform can deliver proper Comet support. AsyncWeb here is > > > just an example that can serve as a reference implementation. > > > > > > Im not sure, nor am I > > > > familiar with them in great detail but your right, there are a lot of > new > > > > options now that didn't previously exist so we should be considering > them. > > > > > > Today I read a preso that was suggesting servlet 3.0 wont deliver > > > > feature-full cross-container comet support as everyone had hoped; if > that's > > > > the case, then sure, supporting other architectures would probably be > a > > > > pretty good idea :-) > > > > > I think that supporting other non JEE architectures is important > > > regardless if servlet 3.0 can deliver or not their claims. Widening > > > Lift underlying HTTP platform would be a huge gain IMHO. > > > > > > Cheers, Tim > > > > > > On 25/07/2009 19:06, "Marius" <marius.dan...@gmail.com> wrote: > > > > > > > Hi, > > > > > > > Did anyone "played" with AsyncWeb? .. Looks pretty promising but I > > > > > think having Lift working properly with it we need some adaptions. > For > > > > > instance: > > > > > > > 1. Lift uses HttpServletXXX references provided by JEE containers. > One > > > > > solution that avoids vast code change is Lift is to bridge AsyncWeb > > > > > API through our own implementation of HttpServlet, HttpServletXXX > etc. > > > > > > > 2. Session management .. We'd also need a bridge for HttpSession .. > > > > > but that should be pretty straight forward. (Fortunately we have > > > > > LiftSession only bridged to HTTP session today.) > > > > > > > 3. Comet support. Async Web fundamental concept seems to map pretty > > > > > well to Comet model. Probably they don't have the suspend/resume > > > > > mechanism as Jetty but there are some other means to do it right. > Need > > > > > to look more into it ... > > > > > > > The point is that perhaps we should expand a bit and not depend so > > > > > much on JEE web container anymore as there are other viable > > > > > alternatives. We just need to build a flexible and transparent > wiring > > > > > mechanism. > > > > > > > I'll probably start looking more into this path but first I'd like > to > > > > > see your thoughts ... > > > > > > > Br's, > > > > > Marius > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
