[Fwd: Re: [Fwd: ICEfaces Ajax URL determination]]

[Michael Freedman <michael.freedman@oracle.com>]

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