Server TF Minutes 2006-11-29

From MemberWiki

Jump to: navigation, search

Minutes stored at url: /member/wiki/Server_TF_Minutes_2006-11-29

Contents

Attendees

  • Chris Schalk <chris.schalk@oracle.com>
  • Christophe Jolif <cjolif@ilog.fr>
  • Greg Wilkins <gregw@webtide.com>
  • Jon Ferraiolo <jferrai@us.ibm.com>
  • Shel Finkelstein <shel.finkelstein@sap.com>
  • Ted Thibodeau <tthibodeau@openlinksw.com>
  • Ted Goddard <ted.goddard@icesoft.com>

Original Agenda

  • Agenda
    • Introduction
    • Server Integration Technology review
      • Discuss common approaches between different technology architectures
      • Plan forward:
        • Attempt to evolve from varied approaches into unified common architectural approach
        • Use this to drive upcmoning Use cases and Requirements
        • Pass on info to the larger Working Group
    • Perhaps discuss non-JSF integration
    • Wrap up

Minutes

Topic: Introduction

CS: Looks like neither Craig or Greg will be attending.

CS: There is some new content. Helped me.

CS: Quick review of agenda. We will review survey and try to get on same page. Then maybe start work on uses cases and requirements. Maybe others will provide their experiences. Curious about jmaki and Sun and their approaches. Any other things to add to agenda?

JF: I didn't see anything in survey reports about how Ajax components are integrated.

CS: OK, let's ask authors about this as they describe their write-ups.

Topic: ITMill

CS: ITMill?

(Joonas wasn't present, so we skipped this.)

SF: Good if the wiki page shows who is the author of each section.

Topic: ICEfaces

TG: Extensions to JSF. Emphasis on push and ability to update any part of the tree. DOM is on server. Changes are detected and sent to browser for updates. We see greatest opportunity for interoperability on the server.

JF: How does DOM work? Replicate the HTML DOM on the server?

TG: Not the HTML DOM. But there is a document DOM on the server now.

CS: How do other toolkits integrate?

TG: Client-side integration mainly. If Dojo sends XHR directly, that will conflict with ICDfaces which uses all connections for push and other communications needs.

TG: Blocking servlet does queueing and enables long connections.

JF: How would a dojo-derived charting widget fit in?

TG: Our request is to use widget as DHTML rendering but hook into ICEfaces for DOM manipulation.

CS: Ideal situation would be to have a simple wrapper like Jon mentioned earlier.

JF: Ideal if no rewiring of Ajax components for each server framework.

CS: Don't see how to do it now, particularly bridging between JSF and ASP.

CS: Kind of like jmaki. agnostic to Dojo or YUI or whatever. Able to abstract toolkit-specific features. How would you compare/contrast with ICEfaces approach?

TG: ICEfaces is technology for manipulating the page. Other approaches have taken a component-specific approach. I need to look at how jmaki works.

CS: Maybe branch with 2 approaches. DOM manipulation method is one way, as opposed to component method, and make jmaki is a 3rd approach.

JF: My instincts are to do a wrapper at the pojo level. Then have standard mapping layers on top of that for JSF.

CS: Maybe put something visual on wiki page for what you are thinking.

JF: Sure, but still trying to get a better feel from survey.

TG: Dojo component can exist on page but won't take full advantage of ICEfaces framework on server.

CS: Is all JS encapsulated on server?

TG: Yes

Topic: ILOG

CS: Maybe highlight differences vs. ICEsoft

CJ: ICEsoft requires people to make communications compatible with their framework that sits between. Big difference versus ICEsoft is that we don't provide a similar framework. Use standard JSF without an additional layer. So, Ajax push isn't available. Two ways to integrate with JSF. 1. Call JSR servlet with an extra param ajax=true. Server listens for attribute and if true builds a response to update only part of the page.

CS: PhaseListeners were touched on in my book. This approach doesn't have a DOM approach. For example, a suggestion feature like Google Suggest. Component has JS.

CJ: Yes. If server request, phase listener deals with partial update.

CS: PhaseListeners allow intercepting any request. The approach you are describing is what we described in the book.

CS: What about relationship to wrapper approach?

CJ: We can integrate with JSF services. But to abstract things and generalize, I would not want dozens of listeners to dozens of components. Don't see yet how to generalize. Another problem is portlet mode. In portlet mode, things are caught by portal container, which regenerates entire portal page. Even if one portlet needs update, all portlets get redrawn.

CJ: Maybe portlet specs will improve this.

CS: Does anyone know someone in portals?

CS: Christophe, anything else?

CJ: We have another technique. Separate servlet for Ajax requests vs portlet servlet. Advantage is that it works directly. Disadvantage is that it is not part of JSF life cycle. Sometimes requires a lot of work to integrate with JSF logic.

CS: Same as we found when doing the book.

CJ: I started talking with one of our .NET experts. It has something corresponding to servlets. They have something comparable to Faces framework and something similar to PhaseListener.

CS: Bit missing hole we have is ASP.

CS: I will add more info to survey using information from book. It will mirror what you are saying.

CS: In our experience, main challenge is to render JavaScript as well as porcess XHR that comes from client. 2 main courses as Christophe describes. We described a 3rd way also.

CS: For 1.2 of JSF, more features are getting added, but nothing really major as far as I know.

CS: Would be nice to see jMaki. Can ask Greg.

CS: If Greg can't do it, I have some familiarity. He had a high level set of tags that wrapped the component.

CS: I might have som emore info on survey about an upcoming product. Some overlap with ICEfaces.

ACTION: CS to ping Greg about adding jMaki info to survey page

ACTION: CS to add a small entry about jMake to survey page

ACTION: CS to add updates to survey page from his book

ACTION: CS to ask Oracle for permission to talk about new product

CS: Would be good to have an ASP person.

JF: Yes, but Christophe's report on ASP is reassuring that the differences won't be too dramatic.

JF: Good progress, everyone!

CS: How about alternating weeks with Communications Hub?

GW: I like it the way it is.

JF: I agree with Greg.