[JAVASERVERFACES_SPEC_PUBLIC-307] Ajax Push (Reverse/Comet) Created: 18/Sep/07  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: Macintosh

Issue Links:
blocks JAVASERVERFACES_SPEC_PUBLIC-293 Ajax umbrella issue Closed
Issuezilla Id: 307
Status Whiteboard:

cat2 frame size_large importance_medium


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.

Comment by rogerk [ 18/Sep/07 ]

Set target milestone 2.0

Comment by Ed Burns [ 09/Sep/08 ]

Push to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by rogerk [ 20/Jan/10 ]

Target 2.1

Comment by Ed Burns [ 02/Mar/10 ]


Comment by Ed Burns [ 22/Mar/10 ]


Comment by Ed Burns [ 22/Mar/10 ]


Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]


Comment by rogerk [ 27/Oct/10 ]


Comment by rogerk [ 16/Nov/10 ]


Comment by arjan tijms [ 09/May/13 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Generated at Mon Feb 27 17:20:27 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.