• Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Ajax/JavaScript
    • Labels:
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
    • Status Whiteboard:

      cat2 frame size_large importance_medium

      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.

        Issue Links



            • Assignee:
            • Votes:
              5 Vote for this issue
              3 Start watching this issue


              • Created: