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

[Subbu Allamaraju <subbu@bea.com>]

This is coincidental. I'm looking into the same issue this week, and 
having some off-line discussions with Ted.

Subbu

Michael Freedman wrote:
> 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-
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [Fwd: ICEfaces Ajax URL determination]
> From:
> Ted Goddard <ted.goddard@ICESOFT.COM>
> Date:
> Tue, 21 Nov 2006 11:36:54 -0700
> To:
> JSR-301-EG@JCP.ORG
> 
> To:
> JSR-301-EG@JCP.ORG
> 
> 
> 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
>>>

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.