[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: [Fwd: ICEfaces Ajax URL determination]]
FYI ... one thing I forgot to include in my Ajax writeup was one use/requirement that some of these Ajax request rely on "blocking http requests" so that push function can (continue to) be supported. Subbu, another consideration to account for? -Mike-
--- Begin Message ---
- From: Ted Goddard <ted.goddard@ICESOFT.COM>
- To: JSR-301-EG@JCP.ORG
- Date: Tue, 21 Nov 2006 11:36:54 -0700
Perhaps I should add a bit more from the ICEfaces perspective: The amount of code actually in the Servlets that ICEfaces makes use of is not that great, so if there is a natural way to implement what we need entirely within the Portlet environment, a port isn't out of the question. (We are hoping, however, for as much re-use as possible between the Servlet and Portlet environments.) What is a concern, though, is whether a given Portlet environment will accommodate the blocking HTTP requests that we use for Ajax Push, and whether we can hand these requests off to our separate asynchronous HTTP if need be (this server makes use of non-blocking I/O to handle large numbers of blocking connections with a bounded number of threads). If Portlet environments vary in their ability to handle blocking HTTP requests, we may be better off maintaining the separate servlet for the Ajax interaction. Regards, Ted. On 21-Nov-06, at 11:13 AM, Scott O'Bryan wrote: > My personal opinion is that doing things for Portlet 1.0 is a waste of > time/resources. At best we have to come up with a real hacky > implementation which will (hopefully) only be in place for 6 months > or so. > > The reason I bring up the Portlet 2.0 Usecase as it pertains to ICE is > it seems from the comment that they are handling AJAX through their > own > servlet rather then the faces foundation. If this is the case, they > either they are going to have to totally re-implement the solution > using > the Bridge instead of their own custom servlet, or we're going to have > to allow them custom plugins which will allow us to solve their > requirements. Otherwise, they'll be stuck making a resourceRequest > rather then the "proper" action request. > > I suppose it's clear, however, that there is just too much uncertainty > in this space and AJAX implementations in faces are going to have some > key differences that I don't really think we can solve now. Maybe > it'll > be time for a second pass at this after the Portal 2.0 is released or > later in the JSF 2.0 development cycle. > > Scott > > Kito D. Mann wrote: >> FYI, there's a lot of work in the Portlet 2.0 spec regarding AJAX >> requests >> and so-on. I'm not convinced there's anything else we need to do >> for portlet >> 2.0 other than make sure this bridge works well with it. The real >> question >> is whether to do anything about portlet 1.0. >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Kito D. Mann (kmann@virtua.com) >> Author, JavaServer Faces in Action >> http://www.virtua.com - JSF/Java EE consulting, training, and >> mentoring >> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info >> phone: +1 203-653-2989 >> fax: +1 203-653-2988 >>--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]