From MemberWiki

Minutes stored at url: /member/wiki/Server_TF_Minutes_2007-03-07

Attendees

• Ric Smith <richard.allen.smith(at)oracle.com>
• Christophe Jolif <cjolif (at) ilog.fr>
• Jon Ferraiolo <jferrai (at) us.ibm.com>
• Ted Goddard <ted.goddard(at)icesoft.com>
• Craig McClanahan <Craig.McClanahan(at)sun.com>
• Joshua Gertzen <jgertzen(at)customcreditsystems.com>

Original Agenda

• Agenda
  • Discuss attendance and agenda for Face-to-Face
  • Review and formalize thoughts presented in past two regarding server side hub and push standards
  • Handle any outstanding business
  • Wrap up

Minutes

Ric: There are essentially three things we have been looking at over the past few weeks.

1. Standardize push APIs across technologies
2. Server-side event hub
3. Tag descriptors or meta data for Ajax components

Craig: Server messaging format for events and components is essential. This is really what will allow us to push a standard. Most of the JCP specs come from an existing protocol. Similar to what happened with to HTTP and Servlets.

Craig: I have some concern that we are going outside of the OpenAjax charter in this area.

Jon: If this works to the benefit of the OpenAjax community then we can consider it.

Craig: GlassFish contains APIs called Grizzly that allow asynchronous communication.

Josh: If we are going to build a reference implementation, it should be built over top of the existing Servlet architecture rather than proprietary APIs like Grizzly.

Ted: I think it makes sense to build a Servlet implementation.

Josh: If you take push out of the equation the Servlet implementation can scale well. In terms of the event bus, I see a need for both. The spec needs to be flexible enough to handle both. So responses can be generated asynchronously or as a response to a client.

Ted: We desire an opaque message format, but when serving different components this may not be possible.

Josh: May be as simple as building a representation that can be built both ways and async can be turned on or off.

Craig: I think the need for both highlights the need for a standard. I have been lobbying for changes to the Servlet spec at Sun.

Ted: Two encodings possible JSON or XML. Which way do we go?

Josh: JSON preferred but possible to use both.

Ted: We avoid JSON since it is an executable injection.

Josh: It is an executable in the since that you can do an eval.

Ted: We spent the last decade building up the XML infrastructure.

JON: JSON is the thing these days.

Josh: Comes down to a matter of whether you trust the server and the content it is emitting.

Jon: Is there a way that we can do both and point out the potential security issues if you use JSON. For example, a scripted parser for JSON and a trusted server.

Ted: We would want to purge the eval implementation from the hub if a developer chooses to use XML.

Jon: Our reference implementation would have a JSON parser rather than performing evals. Other implementers of our spec can create implementations that use evals.

Josh: We may want to ask our selves what are the potential risks. At some point it is the browsers responsibility.

Jon: In a mashup scenario we don’t know what the content is so we may not want to have the eval.

Josh: Maybe as part of the data format we want to flag stuff appropriately. That way the hub can figure out whether to evaluate the format or not.

Craig: If we proxy on the server-side, the server-side can filter out insecure messages.

Josh: I like the idea of having the server filter messages out. That way we can validate event structures. This would mitigate the issue of executing an eval on the client.

Jon: I think we want to take security into account, but allow implementers to identify shortcuts if needed. We need to keep these things in mind but start working towards requirements.

Jon: Thinking we should have a 20 minute information presentation at the face-to-face.

Ric: Sure

Jon: Do you think we should have a communications working group?

Ric: I think this is a good idea.

Jon: jMaki provides a taglib for components. This is more of an integration task which we should move to a separate working group. Considering two working groups. One for Communicaiton and the other for integration. I will propose this to the steering committee this week if we meet.