Ajax Push (Reverse/Comet)

eclipse-faces-bot commented 17 years ago

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.

Environment

Operating System: All Platform: Macintosh

Affected Versions

[2.0]

eclipse-faces-bot commented 5 years ago

Issue Imported From: https://github.com/javaee/javaserverfaces-spec/issues/307
Original Issue Raised By:@glassfishrobot
Original Issue Assigned To: Unassigned

eclipse-faces-bot commented 17 years ago

@glassfishrobot Commented Reported by rogerk

eclipse-faces-bot commented 17 years ago

@glassfishrobot Commented rogerk said: Set target milestone 2.0

eclipse-faces-bot commented 16 years ago

@glassfishrobot Commented @edburns said: Push to 2.1