Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: rogerk
Votes: 5
Watchers: 1

If you were logged in you would be able to see more operations.

Ajax Push (Reverse/Comet)

Created: 18/Sep/07 01:19 PM   Updated: 24/Jan/14 09:39 PM
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: 2.3

Time Tracking:
Not Specified


Operating System: All
Platform: Macintosh

Issue Links:

Issuezilla Id: 307
Status Whiteboard:

cat2 frame size_large importance_medium

Participants: arjan tijms, Ed Burns and rogerk

 Description  « Hide

The specification must define the APIs/SPIs for pushing server side state
changes to the client (a.ka. comet, reverse ajax,...).
Norbert Truchsess wrote:
> For real asynchronous comet-style communication there is an api to
> access the component-tree asynchronously on the server not in response
> to an HttpRequest (e.g. from a message-driven bean). Any change to the
> tree- and component state would be send to the client with the next
> response. In case of client-site statesaving the 'non httprequest based'
> call would be queued until the next HttpRequest comes in, then the state
> would be restored, the queued 'non-httprequests' would be processed in
> the same order they arrived and after that the regular processing of the
> HttpRequest would continue. In case of client-side statesaving where a
> communication-channel to the client is allready open (e.g. by means of a
> 'delayed' request that does not nessesarely contain the state) the
> delayed request would be released first, if it contains the state
> processing could continue as in the 'serverside statesaving' case. If no
> state is included in the request there would be an immediate response to
> the client containing a message that forces the client to send the state
> in a new request and processing may continue as described before.
Roger Kitain wrote:
Sounds interesting. But how does this tie in with the inclusion of "Comet" in
the Servlet specification (JSR 315)? Does that simplify what you describe here?
Norbert Truchsess wrote:
> The JSR 315 proposal talkes about non-blocking
> input/output, delayed request-handling, delayed response-close and
> Blocking/nonblocking notification (channel concept with the ability to
> subscribe to and get asynchronous events from that channel). The first 3
> items are just nessesary to do the client/server-part of the
> communication. If the last item (blocking/nonblocking notification) is
> describing a server-side feature (it sounds like the description of an
> existing feature in Grizzly), then it might/will help a lot to implement
> what I described above.
Ted Goddard wrote:
> The approach taken by ICEfaces is essentially to allow the
> application to retain a reference to the FacesContext outside
> of the servlet request/response (we call it a PersistentFacesState).
> Then, the application can invoke render() on the associated
> component tree at any time, causing any page updates to be pushed
> to the client. Only one simultaneous render of the component tree
> is allowed, so client-initiated updates and server-initiated updates
> are applied coherently.
> We did not support client-side state saving with Ajax Push because
> a server-initiated update is only meaningful when the server has
> full knowledge of what it is updating ... but perhaps there is
> a use case where it can be applied.
Norbert Truchsess wrote:
> Shure there's no gain in doing
> server-initiated updates without having access to the state on the
> serverside. But 'having' to retain the complete state on server (as it's
> done by ICEFaces results in quite limited scalability due to memory
> consumption. It would be beneficial to mark which parts of the
> component-tree-state are required during a server-initiated update so
> either only this part would be stored on the server or only this part
> would have to be 'requested' from the client before a server-initiated
> update could take place.

> My opinion here: let's target best of breed support for ajax in the
> framework itself. And that is support for 'real' comet-style push
> updates that can be used without any vendor-extensions 'out of the box'.
> We all know that the jcp is turning much slower than the techniques
> being used in the real world are evolving. At the time JSF 2.0 will be
> ready to ship the ajax-techniques being used out there world will be way
> more advanced then they are now and I bet support for
> comet-communication will be commodity in most 'non java based'
> web-application frameworks. If we don't have support for this 'build
> into the bases', jsf 2.0 will not be as attractive as it could be.
> Shure, not everyone needs it. Most enterprise-applications will do
> without it. So it should be optional to use - best would be to be able
> to switch in on/off at runtime for precisely that single page that e.g.
> contains a 'chat-component'. But wouldn't it be really cool, if you
> could use a chat-component by just placing it on the page and set
> 'communicationStyle="comet" in the view-tag? I'm more than convinced
> that this feature would rise the recognition of JSF as a modern
> technologie way more than most other things on our roadmap will do.
> This particular issue should not be priorized low just because a lack
> of resources in this EG. I hereby volunteer to write this chapter, the
> code and the tck even single-handet if no one else is willing to do
Ted Goddard wrote:
> Ajax Push (also known as "comet", although that tends to
> refer to the Dojo implementation) is the main distinguishing
> feature of ICEfaces. ICEfaces is open source, so there is
> no barrier in principle to incorporating any desired
> parts of it into JSF 2.0.
> In terms of the technology, should it be part of JSF 2.0?
> - the server infrastructure really requires changes to the
> Servlet API (although asynchronous I/O is a goal of JSR-315)
Norbert Truchsess wrote:
> I did invest quite some time to dig through ICEFaces
> implementation details, and from an architectural point of view I like
> it a lot. So if there would be no memory-contrains in reall-world
> scenarios I'd love to just take and transfer it into JSF 2.0. And in the
> reall world developers will not want to be constrained in using
> client-side widgets that do dom-manipulations on the client. (which also
> would be in conflict with our first assumtion 'Ajax.A01')
Ted Goddard wrote:
> It's the JavaScript aspect that makes me hesitant to advocate
> Ajax Push for JSF 2.0 (since the Servlet changes are on the
> horizon), but I could certainly be persuaded otherwise.
Roger Kitain wrote:
If would like to focus more on what's required on the server to facilitate this
feature, and ** not ** standardize lots of javascript (if that's possible).
Norbert Truchsess wrote:
> 100% agree - Not
> that I think we could go without JS on the client here, but the the
> server-side requirenments are the prerequisite that has to be done first.

rogerk added a comment - 18/Sep/07 01:20 PM

Set target milestone 2.0

Ed Burns added a comment - 09/Sep/08 12:58 PM

Push to 2.1

Ed Burns added a comment - 24/Nov/09 07:48 AM

Prepare to delete "spec" subcomponent.

Ed Burns added a comment - 14/Dec/09 08:59 AM

Move these to unscheduled because we need to target them correctly. isn't
specific enough.

rogerk added a comment - 20/Jan/10 10:25 AM

Target 2.1

Ed Burns added a comment - 02/Mar/10 05:14 PM


Ed Burns added a comment - 22/Mar/10 06:44 AM


Ed Burns added a comment - 22/Mar/10 11:42 AM


Ed Burns added a comment - 15/May/10 07:54 AM

These are targeted at 2.1.

rogerk added a comment - 17/Jun/10 10:21 AM


rogerk added a comment - 27/Oct/10 10:58 AM


rogerk added a comment - 16/Nov/10 11:38 AM


arjan tijms added a comment - 09/May/13 04:51 PM

Now that WebSockets have been standardized in Java EE 7 (JSR 356), it might be the right time to reconsider standardizing push for JSF.