2007 September Members Meeting Minutes

From MemberWiki

Jump to: navigation, search

Contents

Wiki pages for the OpenAjax members meeting of September 27, 2007

The following are the various wiki pages for the OpenAjax Alliance's members meeting that happened on September 27, 2007:

Attendees

  • Jon Ferraiolo, IBM
  • Bertrand Le Roy (Microsoft)
  • Gideon Lee (OpenSpot)
  • Steve Hunt (Coradiant)
  • Jani Laasko (IT Mill)
  • Kai Hendry (Aplix Corp)
  • Dave McAllister (Adobe)
  • Mike Pittaro (SnapLogic)
  • Rick Saletta (ActiveGrid)
  • Greg Murray (Sun)
  • David Boloker (IBM)
  • Stewart Nicholas (IBM)
  • Krishna Akella (IBM)
  • Ingo Muschenitz (Aptana)
  • Krishna Shankar (Cisco)
  • Ric Smith (Oracle)
  • Erwan Paccard (ILOG)
  • Coach Wei (Nexaweb)
  • Dipesh Patel (Fidelity, Boston)
  • Ted Goddard (ICEsoft)
  • Steve Maryka (ICEsoft)
  • Larry Lieberman (Microsoft)
  • James Pratt (Microsoft)
  • Rhys Lewis (Volantis)
  • Dan Appelquist (Vodafone)
  • Rotan Hanrahan (MobileAware)
  • Michael Smith (W3C)
  • Howard Weingram (TIBCO)
  • Mike Milinkoich (Eclipse)
  • Alex Russell (Dojo, Sitepen)
  • Shel Finkelstein (SAP)
  • Chris Mitchell (IBM,Dojo)
  • Adam Peller (IBM,Dojo)
  • Scott Dietzen (Zimbra)
  • Dave McAllister (Adobe)
  • Steve Hunt (Coradiant)
  • Yuecel Karabulut (SAP)
  • Chris Schalk (Google)
  • Dion Almaer (Google, Ajaxian)
  • Othman Laraki (Google, Gears Product Manager)

Slides

A PDF of the main slide deck used by Jon Ferraiolo during the F2F can be found at:

Other slide decks used during the day:

Minutes

Early morning 8:00 - 10:30

8:30-9:00 - Welcome

  • The Steering Committee will welcome the attendees
  • Jon will show the agenda and (with help from Microsoft people) explain any important information for the day, such as availability of wireless

Steering Committee Welcome

(Jon invites all Steering Committee members who have arrived so far to come to the front and give welcoming comments. David Boloker of IBM, chair of Steering Committee, Scott Dietzen of Zimbra, and Coach Wei of Nexaweb come forward)

David: Scott and I had the idea originally. We have come a long way. What was clear was that vendors had different ideas about how to do Ajax and that customers wanted to use multiple toolkits on the same page. We have now produced many things, including the Hub and various white papers, including the recent one on security. I look back at the first year. Unbelievable progress. Four or five committees, including new ones starting today. We now have an intense focus outside on a lot of the work that we are doing. All great news. Each and every person in the audience needs to be thanked for helping to move things forward. Also, seeing a definite change in terms of who is coming in. More customers now instead of vendors. So we have made a lot of progress and want to thank everyone.

Coach: Second David's comments. It has been my great pleasure to work with all of the smart people. OpenAjax Hub 1 is going to have a great impact and is solving some real problems. I am definitely looking forward to continuing to work with everybody, including on the next version of the OpenAjax Hub, which will be even more amazing.

Scott: Going back those two odd years ago. Zimbra's app is now over 100K lines of javascript. But it was clear that toolkits and tooling wasn't up to task. Our motivation was selfish - we wanted things to improve for our own needs. Things have gotten better and we have had some hand in that. It still feels like end users need a lot more help. Ajax is within the grasp of leading software companies but not necessarily ready yet for mainstream users. We have to keep making it easier. There is an opportunity to step into this organization and lead. In standards bodies it's the people who want to lead that ultimately can have the greatest impact. We didn't know where this thing would go. We knew we needed help, such as consolidating our innovations. I hope this group can continue to help drive that process along.

Introductions

Jon: Let's have everyone introduce yourselves.

Bertrand Le Roy (Microsoft): I'm Bertrand Le Roy and I work for Microsoft.

Jon: Bertrand and MS are hosting this meeting and we want to thank them for their generosity.

Jon: OK to say which committees.

Bertrand: I'm in Interop, Security and IDE.

Jon: Also, ok to say if you pass the InteropFest. Microsoft did.

Gideon Lee (OpenSpot): Interop, Communications Hub, Security, InteropFest.

Steve Hunt (Coradiant): Trying to get new task force started on Production Ajax Management, managing Ajax in production environment.

Jani Laasko (IT Mill): We passed InteropFest. Toolkit vendor.

Kai Hendry (Aplix Corp): I'm new and looking where I can help. Mobile TF. My background in WhatWG and HTML.

Dave McAllister (Adobe): Will talk about Searchability TF.

Mike Pittaro (SnapLogic): Recent member. Just joined. Odd guys out in that we are working on server data layer. But people say we needed to be compatible with JS in the browser.

Rick Saletta (ActiveGrid): Director Product Management. Just acquired Turbo Ajax Group. We are pursuing a new direction which we will be announcing this fall. We feel Ajax standards are needed for the Enterprise.

Greg Murray (Sun): Work on jMaki most of the time. Another Sun person will help focus on OpenAjax soon. Interop and IDE. jMaki works with Netbeans and Eclipse.

David Boloker (IBM): Me again. I try to get to Marketing, Interop, and Security. Today Stew Nickolas and I will be presented a widget spec and hopefully will kick off a new activity here.

Stewart Nicholas (IBM): I will be talking about industry momentum around widgets which will interact with other work at OpenAjax around IDEs and security.

Jon: You are Mr. QEDwiki

Stew: Yes

Krishna Akella (IBM): Work with David and Stew.

Ingo Muschenitz (Aptana): IDE working group

Krishna Shankar (Cisco): Interop. Want to join accessibility group.

Ric Smith (Oracle): Product manager. Was in Server, disbanded, Communications Hub, disbanded, now Interop.

Jon: Not disbanded! Integrated into the other groups.

Erwan Paccard (ILOG): Components for maps, diagrams and other things. Ajax versions of these components. I am in marketing. Colleagues are in others.

Jon: Yes, Christophe is in Interop and IDE.

Coach Wei (Nexaweb): We write Javascript for a living. We have recently made a contribution of a fairly cool grid component to Dojo. I was chair of Communications Hub task force, which is now rolled into Interop WG, so I am involved there. Going forward I will probably get involved with mashup, widget and mobile activities.

Dipesh Patel (Fidelity, Boston): I manage a team responsible for establishing an ecosystem for systems we use. We are in Security, Interop and IDE.

Ted Goddard (ICEsoft): Was in Communications Hub efforts around Ajax push and now in Interop. I want to emphasize that in addition to our working on unified APIs to hide browser problems we can work with browser vendors to fix those problems.

Steve Maryka (ICEsoft): We are also the odd man in that we try not to do JavaScript. Security and mobility are areas of high interest.

Jon: Steve gave a good talk on mobile devices at AJAXWorld.

Larry Lieberman (Microsoft): With Windows Mobile team. Here to begin our engagement with the OpenAjax mobile efforts.

Rhys Lewis (Volantis): I'm CTO. We are even odder. We do server-side adaptation. We try to generate Js on behalf of authors who write in a declarative way.

Dan Appelquist (Vodafone): One of the latest members.

Jon: You and W3C are the latest members.

Dan: What's british phone company's interest? From an application development on mobile. We see Ajax as key technology for mobile app development. Another role is I am chair of W3C Mobile Web Best Practices working on guidelines for best practices. Our two objectives: looking in mobile ajax and mobile tf and assuring there is alignment between OpenAjax and W3C.

Rotan Hanrahan (MobileAware): Chief innovation architect. I'm chair of W3C Device Description WG. Use contextual information about mobile devices to enable adaptation of Ajax applications.

Michael Smith (W3C): Just since Jan at W3C. I am staff content at MW BP and DD WG. Part of Mobile Web Initiative at W3C. Have worked at Openwave and Opera and other mobile companies.

9:00-9:30 - Lightning review of current activities

  • Jon will provide a brief summary of the state of all of the working groups and task forces


Jon: Latest AJAXWorld magazine has an article "Remarkable First Year" that summarizes what we have accomplished, what we are working on, and some of our plans for the future. There is a stack of magazines up here in the front.

Jon: Here is a slide I show at conferences about why the alliance was formed. Why did we form OpenAjax Alliance? Ajax has lots of momentum. I talk about the need to use multiple toolkits and the need to integrate. Therefore, most of our technical work is about the word "interoperability" to get Ajax products to work with each other. Then there is this issue of educating the community about how to be successful. Evangelism, marketing and education, these sorts of things. When we had our kick-off meeting last year, we agreed on these two fronts, technical and educational.

Jon: Next slide shows a summary timeline of the various activities we have going and when they started. Scott & David started talking in 2005. In Feb. 2006, 15 companies said they were for "OpenAjax", sort of "yeah we are for Ajax and we are for open". But first meeting to decide what it meant and what to do wasn't until May 2006. After that meeting we started working on a white paper and started an interoperability committee. At the first meetings, there was no notion of doing a Hub. Wasn't an initial decision. This came out of our discussions about what we should do and was spurred by an open source contribution by Tibco and Dojo, and then Nexaweb, and probably some others. We had proposals to do the Hub and then what things the Hub should do. We held discussions and worked iteratively over multiple passes on it until the Hub is what it is today.

Jon: The Hub was the first major technical work. By end of 2006, we had a complete spec and open source. Then had our first InteropFest from Jan to Mar. Afterwards, we talked about what we learned, what features were good and which were problematic. We mainly streamlined, to about 1/3 of the size, making the Hub have fewer features and a smaller download. Some people said a small footprint was critical because if small enough, it would just get bundled with key toolkits. In fact, we got it under 3K in the reference implementation and as a result it will be bundled with Dojo 1.0. That's big because of indirect inclusion of many products that build on Dojo. Lot's of products use Dojo, like the XAP toolkit and the QEDwiki mashup container. TIBCO GI is likely to include OpenAjax Hub. So, by shrinking it we are driving adoption.

Jon: Today we completed our second InteropFest. You'll see the list of companies and toolkits later along with demos.

Jon: Last stage with Hub is getting through approval process.

Jon: That's the Hub. In parallel with the Hub we started other technical activities. The slide shows them. The slide leaves off the Server TF, which it shouldn't have, even though this is a simplification diagram. Server and CommHub were in parallel. Chris Schalk and Ric Smith led server, Coach led CommHub. Clearly not disbanded in either case. Lots of product out of each. Specification proposals, open source contributions, use cases and requirements from both. These results were then handed over to the other committees which built from there. All of this informed the Hub 1.1 roadmap. The new features of Hub 1.1 are mainly from the work of two channels, Security TF and CommHub TF, which in turn was informed by Server TF.

Jon: At end of 2006 and beginning of 2007, we started our IDE effort. First a TF then a WG. We have now gotten through use cases and requirements and have 3 proposals for the file format, and probably a 4th one coming soon. Soon make decisions about format for metadata and start working on a spec.

(Bertrand suggests an IDE interoperability event. Jon and others support his suggestion.)

Jon: Launched security in spring and mobile in summer, and two more task forces we will talk about today.

Jon: Key takeaway is that we are adding new activities over time and broadening our scope, but all around interoperability, which is our focus.

Jon: Now slide on membership growth. As of today, 92, with latest members being Vodafone and W3C. Vodafone is largest operator?

Dan: Second to China Mobile.

(Jon continues on with slide deck. Very successful week in media attention on OpenAjax with Jon as Tech Chair of AJAXWorld, 3 articles in AJAXWorld magazine, and good press. Major achievement with security white paper. Lots of touch content in a short period. Collaboration among industry experts from multiple companies starting paper from IBM research.)

(Jon goes over technical accomplishments. Hub 1.0 about done. Hub 1.1 in process. IDE WG working on proposals. Security TF made progress in short amount of time. Mobile TF also clear progress in just a couple of months. Subsequent sections on security and mobile)

9:30-10:15 - OpenAjax Hub 1.0 and the InteropFest

  • Members can get up and show off their use of the Hub
  • Discussion about finalizing and approving the specification
  • Schedule Creation Review phone call?

(Jon goes over Hub 1.0 slides - what it is, how it works. About 20 companies and about 20 toolkits participated in InteropFest. Major success.)

(About six companies give demos out of the 20 contributions. This list of demoes might not be fully accurate, but here goes from memory: Lightstreamer, with server push and Dojo charting; Nexaweb, showing a declarative XML grammar which integrates with Hub; ILOG, with drag/drop from Dojo toolbar onto diagram editor via Hub; Microsoft, with general bridge JavaScript from their event system onto Hub; Dojo, with JQuery and Flickr integration; and OpenSpot.)

(Discussion about whether we can now go to final approval with Hub 1.0. Consensus: yes)

ACTION: Jon to schedule a Release Review phone call to resolve any final issues with the hub and approve publishing the spec

10:15-10:30 - OpenAjax Hub 1.1

  • Jon will summarize status, plans and target schedules
  • Communications Hub Task Force merged into Interoperability WG to add Comet support to Hub 1.1
  • Discuss status of secure mashup open source effort (derivative of SMash implementation)

(Jon goes over Hub 1.1 slides. Explains how SMash techniques work for secure mashups with sandboxing via iframes and technique for cross-frame communications. Will lead with open source experiments, just like the early days of Hub 1.0. This has been discussed several times in previous meetings. Just an FYI for those who weren't in other meetings.)

10:30-10:45 BREAK

Late morning 10:45-12:15

10:45-11:15 - Fidelity's Requirements and Proposal for a Service Access Layer (20-30 minutes)

  • Led by Dipesh Patel of Fidelity
  • Topics
    1. Our challenges with Ajax
    2. Proposed architecture / design
    3. Discussion about several key components, the service access layer being one of them

Dipesh explains explains RIA challenges at Fidelity. Most of career on server, but recently into RIA. Data access important to Fidelity. Wants to provide a common higher-level data layer to their businesses and not have them having to deal with low-level like XHR. Common things like security and JSON scrubbing. Wants to provide standard APIs to business units. Quite a lot of work at firm with RIA. Not just for simple applications, but also for mashup applications. Looking to make whole end-to-end experience simple for engineers. Today use things like WebSphere portal server. Investigating whether they can move more things to client and find less complex alternatives. Some of the biggest challenges today are number of choices. Lots of Ajax options. Also lots of options around portals. Also Flex. Looking at Silverlight. Also looking at different programming models, server-centric or client-centric or hybrid. For now, will stick with a Java model. We have thousands of systems out there. Would like to reuse and integrate them into new UIs. Performance is also a concern. Large data sets all of the time. Security very important, wait to avoid becoming a headline. JSON attractive because of performance benefits.

We like to use standards-based approaches. Therefore, very interested in OpenAjax Hub pub/sub model. If SMash is it, then will want to use that. Today for mashups we use server-based proxy, which isn't ideal solution. Yes, we want to use multiple types of components. We use Dojo now, but vendors and other business units might use something else. Try to get users to restrict themselves to a small number of leading toolkits.

We recognize for data access it's not just going to be XML over XMLHttpRequest. Today we don't use JSON because of security concerns. Would like to use AMF at some point because of specialized cases where performance is critical. For example, in some cases we might have 50,000 rows. JSON can't handle that type of information. Name isn't important. A data access layer. We call it Service Access Layer. Takes care of caching and throttling (?) and filters and so forth to decouple from presentation aspects.

We don't want XHR made directly from presentation.

We would like to see a client-side service access layer. Multi-transport (http, sockets), multiple message formats, filters. XML for most cases, but JSON when can be introduced in a secure manner. Plug-in filters so that presentation developers don't have to worry about it. For example, JSON scrubber. Also, could be used for offline access. Data transformation another example. Two callbacks: onResponse, onFault.

ServiceAccessFactory - give it a name, and it opens a facade. The facade can work with any combination of filters and handlers.

(inaudible question from audience)

Dipesh: We have a 5 second response requirement. If it doesn't respond in 5 seconds, engineers get beaten up. (shows demo where JSON is 5 times faster than XML) Want to decouple transport format from developer. Want user to use POST method, but have underlying libraries take care of that. JSON would be faster if there were a way to secure it.

(inaudible question from audience)

Dipesh: We have so many engineering groups for us that we have to mandate don't use JSON because it is possible to have script tag injection, and only allow it on an exceptional basis. Going forward, if we can have this architecture, then just plug in the right filter. This client-side thing should help simplify things on the server.

Dipesh: We don't believe in a monolithic Ajax or Flex application. Need to compose components of approved technologies. Cases for Flex charting or large datasets.

(inaudible question from audience)

Dipesh: Yes, we would need a server-side component to set up the JSON data and put it into a payload.

Dipesh: Overall, we are assemblers. We are consumers of technology. We use Kaplan grid. It may use JSON underneath. From my standpoint, would prefer to use JSON to XML if it could be used securely.

Rotan: Have you looked at W3C work on efficient XML?

Dipesh: We are interested and open to that but haven't looked at it yet. The key thing is JavaScript and it's not there yet.

Jon: Whole Ajax thing is unnatural acts in browser.

Dipesh: Yes

Jon: And after getting things to a certain point we are running into walls. Browsers just need to give us one path to fast, secure data.

Dipesh: Yes

Jon: Regarding service access layer, let's talk about whether we should pursue this in OpenAjax and if so how we would pursue it. My instincts are that we should look at it and make sure that the Hub architecture is compatible with such a facility. Hub 1.1 does have some client-server features and we are planning to factor things with a provider architecture. Maybe SAL is an add-on.

Dipesh: Or optional component.

Jon: Yes. Well that's my initial reaction. Anyone else have comments?

Mike Pittaro: (inaudible - talking about his experience in data access technologies on server - mentions dojo.data - says something about data security)

Dipesh: If you visit a good site, then an evil site, the evil site can get to your cookies via a simple SCRIPT tag. What are the probabilities? Fairly low, but the effect would be very bad.

MikeP: (inaudible, but mentions a recent case that shows the risk)

Coach: When you mentioned multi-transport, have you thought about server push?

Dipesh: Yes, Comet, we have need for both streaming and alerting. We don't have a clear strategy on that yet. Looking at a few vendors, FDS, Kaplan, Lightstreamer. But even with those protocols, we want to have a general model.

Deepak (Jackbe): Your points align with discussions at OpenAjax recently. Jackbe has products and customers in the financial sector. I see your topics are very relevant and our experience validates what you are saying.

Kevin (Tibco): Have been working with Fidelity. We sponsor DWR direct web remoting with a two cookie check for addressing the cookie vs script tag conundrum.

Dipesh: We looked at having a random number that gets verified on the server side. But JSON scrubbing on client approach doesn't require lots of server changes.

Jon: I wanted to ask the dojo team and relationship of SAL to dojo.data.

Alex (Dojo): Are you speaking to browser vendors about getting issues addressed? If not, do you have a list that we could advocate to browser vendors on your behalf.

Dipesh: I don't think it's time yet to give a list to browser vendors. Just make JavaScript faster. Provide ability to do mashups in a secure manner. Also consistency so that we don't have to retest across different browsers because different underlying features are different.

Dipesh: Hub has done a good job with pub/sub and SMash looks promising, but I don't see work yet on data access layer.

Jon: Is Fidelity willing to submit their source code to our open source project?

Dipesh: Need to check with our security folks. I'll get back to you.

Jon: Question is what are next steps. That's why I wanted to get dojo perspective. I believe there are some overlaps.

Chris Mitchell (IBM, Dojo): Within dojo.data, there is a data access API. It is about solving the set of problems you list in your presentation. Doesn't require rest of dojo framework. Essentially a separate project. Might want to look at it.

Dipesh: I want to plug in intercepting filters.

Chris: Yes. There are various layers.

Dipesh: We might be dealing with multiple transports and multiple formats. JavaScript is not designed for everything. May want to use other technologies for certain tasks, but have a single unified API.

Chris: dojo.data is designed to deal with streaming. All async. I would like to work with you about what's in the API.

Dipesh: Right now with dojo 0.4.3. We like how it is designed, like respect for namespaces. But there is the size issue. With dojo 1.0, we are excited about it and the JS size issue is addressed. Maybe use dojo core to build our infrastructure layer.

Chris: (inaudible - something about dojo modules being orthogonal)

Dipesh: OK

Jon: (holding mike but inaudible ramblings)

11:15-11:30 - Production Ajax Management Task Force

  • Led by Steve Hunt of Coradiant
  • What we hope the PAM TF will achieve
  • Call for participants in the TF
  • What do we need to have happen before we start scheduling phone calls

Steve: I hed up engineering for Coradiant for equipment that measures what happens with user and web site to make sure that problems can be addressed before it affects user negatively.

Steve: I want to talk about setting up a TF that instead of focusing on development of web sites looks at production aspects. New style applications are emerging. Little focus so far on production environment. Customers are looking at this on individual basis but no industry wide approach. Reason for coming to OpenAjax - working on mashups, which diversifies away from one-to-one relationship by user to server to multiple servers for each subcomponent. Work in Hub and SMash area will be important. Hub and Communications Hub also helps. Therefore, I expect that most of the production work would align with Communications Hub and Hub 1.1 specification.

Steve: Difficulties. In Web 1.0 world, a transaction is a page. But with new world, messages are passed such as with XML do not provide any standards for identifying which sorts of messages are being passed and who the senders and receivers are. Keeping track would simplify monitoring process.

Steve: I anticipate a series of layers that may be dynamically enabling. Some simple things, basic health, such as successful loading. Easy for simple pages, harder for cross-domain mashups. Then XML tagging, state transitions such as choosing a different tab, ability to turn on lower-level debug logging.

Steve: Asking for new TF. Jon said to present to group to get message out and try to get people involved. TF would define scope of what would be monitored. Define levels. Define methods for captured. Maybe some proposals for 1.1.

Jon: Potentially there is the ideal that we make a proposal that is technically ideal, but what if no one gets on board? In addition to technical issues, there are also real world constraints. With Web 1.0, you could monitor without getting people to change.

Steve: Yes, all transactions could be monitored.

Jon: Would be easy to monitor if everyone agreed to go through same API to go through same state. So part of TF charter should be addressing the adoption issue. Not only what the technology approach should be ideally, but which would get adopted.

Steve: Yes, but first making a proposal. And find horses we can ride. Then it gets down to value and cost to the industry. Need to create a value proposition.

Krishna: We need to expose some of these things. Make sure our technologies have the properties you desire.

Jon: Yes, try to ride horses with legs. Another one to consider is ARIA. They have to keep track of semantics anyway.

Steve: I have looked at it. Some things are applicable. But still a need to incorporate a need to bring access points together.

Alex: It strikes me that some of the essential features need browsers to help, so a good part of this group's work would be advocacy to browser vendors. Also, have you done any prototyping with existing toolkits?

Steve: Mainly looking at what's been going on in this organization and some toolkits to find best leverage points to deploy into the industry.

Kevin (Tibco): We see a strong need in this area. Production management, error checking, things like this. We have some open source. So this is a worthy area, but then we have to ask about prioritize versus other things we are all doing. Have you asked competing companies?

Steve: Already gotten one competitor who has now joined.

Jon: Let's see hands of companies that want to participate. Clearly the interest is high but the question is priorities. (David Boloker of IBM, Bertrand from MS raise their hands. A few others.) I propose that you produce some proposals that can be quickly consumed by the members so people can give quick feedback, such as good idea or not.

Jon: OK thanks.

11:30-11:45 - Ajax searchability task force

  • Adobe will introduce this new task force, explain what it hopes to achieve, and will recruit people to participate in the activity

Dave McAllister (Adobe): Director of standards and open source at Adobe. No Eli Greenfield nor Mark Anders or other experts could make it, preparing for MAX. In June, Kevin Lynch wondered how you search a RIA when data is only available when created on the fly. How do you get back to it? Ajax is huge, but RIA and Ajax searchability is affected. How do you get back to it? We think this is a lack of Ajax and that OpenAjax is the right place to pursue it. With Web 1.0, you click on rocket, it's a deep link and you can record it. With RIA, it's not addressed due to async generation process. We success bringing toolkit vendors and search engines. Define right metadata for applications so that search engines can do deep linking. Searchability and retainable inside search engine structures. Our preliminary suggestion is to continue to use # as deep linking tool and use it to indicate the state of the Web page, no matter Ajax, Flex or Silverlight.

Dave: We want others to join this effort. We want to bring all intelligence in room to this task. Will set up wikis and meetings soon.

Jon: Comments or questions?

Rotan: Introducing metadata has been topic of accessibility activities for years. Might be good to start a liaison with W3C accessiblity and semantic web groups.

Dave: Was a big topic at ISO recently. We worry that some of those initiatives might be trying to solve too big of a problem and we don't think it can move quickly enough.

Jon: We'll start the mechanisms. Gauge the interest. See where it leads. Task forces are supposed to explore an area and determine set of actions. Recommendations for what OpenAjax should do.

Jon: Who is interested in this task force? (Several hands)

Jon: I'll send out notices about these two task forces.

11:45-12:15 - Process and Organizational Issues

Discuss any key administrative and process issues that warrant discussion among the members

  • Reminder: Steering Committee election the following week
    • Note that the F2F meeting happens just before our next Steering Committee election where we vote on 3 of the 7 seats in the Steering Committee. As a result, we will probably discuss process details about the upcoming election.
    • Jon will explain how to operate the voting application
  • Zimbra acquisition by Yahoo and impact on the Steering Committee
  • Discuss implementation/enforcement of "Active Standing" rules within our Working Groups
  • Customer Task Force or Working Group?

Jon: Election is happening right now. If you want to nominate your company, deadline is Sunday. And then next week is voting period. Everyone company gets to choose up to 3 candidates because we have 3 open slots. There is a voting application that I will show. Voting closes end of day on Friday. I'll give background for new members. OpenAjax governance model is simple and lightweight so we can move quickly. Members elect seven organizations to run alliance on their behalf. Nearly all decisions made by SC. In practice, recommendations come from committee and SC just approves, but formal process boils down to these 7 people make decisions.

Jon: I want to thank current SC for their great work so far. Everyone is an executive. They come in with this attitude of professionalism and responsibility. Taking their tasks to heart about serving the membership. So far we have been blessed with no company strategic requests or political issues.

Jon: Last year we help our first election. All 7 seats. Top 4 vote winners got 2-year terms. Next 3 got 1-year terms. Staggered so that we replace about half each year. 3 seats that open: Tibco, Nexaweb and Zend.

(Jon demos the voting app. /member/Election2007/vote.php)

Jon: Please read the instructions so you do the right thing. Step 1, 2, 3. Step 1 is study the nominees. Right now, ActiveGrid, MS, Nexaweb, TIBCO, Zend. Provided short description of their involvement.

(Discussion of Zimbra acquisition by Yahoo. Scott Dietzen says that Zimbra will release its position on SC, since he was elected as leading a small startup. Milinkovich: Yahoo! must take action on membership. jon proposes special election for Zimbra's seat once Yahoo!'s position in known, winner serves out Zimbra's remaining term. Scott may nominate himself to serve again, if possible. After discussion, the members accepted Jon's proposal to keep the Zimbra replacement election as separate from the in-process SC election. There will be a special election to refill the Zimbra seat soon after the current election is over, to complete the remainder of the term of the Zimbra seat. The special election will be modeled after the current election, something like announce, wait 2 weeks, then nomination period of 2 weeks, then election period of 1 week.)

(Jon talks about Active Standing. Proposal is to keep this relatively low key while still honoring this provision of the revised Development Process that the members voted to approve. Each WG maintains a wiki page that shows committee members. Simple check box or something like that indicates whether active. Doesn't have much impact on decision-making. Active standing is only informative to chair and SC when feedback comes in. If someone has been involved, then comments are likely to be treated more carefully, whereas drive-by uninformed comments from someone who hasn't been keeping up might be treated as having less merit. Still, all comments are treated seriously, so shouldn't matter very often.)

(Regarding Customer TF or WG, Jon proposes that for the time being it makes sense for customers to be involved in all aspects of the alliance, not in a special group. No one objected and people went to lunch.)

12:15 - 1:00 LUNCH

Early afternoon 1:00 - 3:00

1:00-2:00 - Offline

  • Google Gears team will lead this discussion
  • Discussion about possible OpenAjax efforts around offline Ajax

Chris Schalk: Talk about offline and Gears and how we might get discussion started. I can give some high level points about Gears. How many people familiar with Gears? (about 1/3)

Chris: The way we see it. More than just offline. Other capabilities to enhance browser. Much better Web 2.0 applications. Main features: LocalServer, provides way to capture external web content for serving when offline; SQL database, using SQLlite; and WorkerPool, multithreaded JS.

Othman: With Gears, tried to do something evolutionary. Didn't want to change the way end users interact with applications or developers. Just a delta on top to make it work offline. Another important piece is development model. Fully open, not centered on Google apps or Google needs. We launched it early so we could get community involvement as early as possible.

Jon: What's the roll-out plan? How do people get Gears onto system? Any partnerships. Certainly, web apps could include JS that downloads the plugin. But other things? Deal with Mozilla, or Apple or MS.

Othman: Yes, sure, we would like browsers to distribute. The fact that it is open hopefully will make browser vendors comfortable. But if not built in, then biggest vector is applications. No intrinsic benefit just from Gears, but from compelling applications that use Gears. Similar to how Flash bootstrapped in the early days. We hope that people come to view that this kind of functionality is expected of the Web.

Jon: So, what does this mean to OpenAjax and what role might we play? MS has a considerable browser market share, and if they don't bundle it, maybe critical mass might happen by Google apps or Yahoo apps if they get on the bandwagon. First, Bertrand, any comments on offline in general or Gears in specific? What's going on at MS.

Bertrand: No.

Jon: Anyone else from MS?

someone: Ask Alex. He seems clued in.

Alex: I'll constrain myself to what I have blogged previously. Google should work to standardize these APIs. The browser in lieu of implementing those APIs themselves would have a responsibility to ship Gears instead. Until then, everyone is just p***ing in the wind.

Chris: With Google Gears, it's not trying to do anything big, just adding a feature and spurring innovation in the community. Since open source, it's not a proprietary thing. I was curious about what OpenAjax Alliance thought, any ideas, any best practices. If alliance is curious about general topic of offline. Second, if people are curious, I can discuss how you might use technology such as Gears.

Jon: Alex said take APIs and make into a standard so browser vendors can implement. So one possibility is to take Google Gears APIs to a standards org like us or W3C.

Othman: We believe standards are important. But we want in early days to get usage so we know if technology is good. Actively working with all standards organizations that want to talk with us. Active discussion now on WhatWG, particularly around LocalServer.

Gideon: Technical issues that make me skeptical. Lots of effort around data sync. Can this really be delivered by 343K?

Chris: Gears is foundational. Not end-all for data sync. It is incumbent on developers to build an appropriate architecture on top. But no recommended approach for data sync.

Gideon: Another question is whether database model is appropriate. Wouldn't it be better to save HTML rather than data.

Chris: That's actually possible. Cache works on HTML. But also can store document in data stores.

Bertrand: Lots of skepticism about plugins. Maybe only plugin today that has worked is Flash. There is a lot of skepticism but I want to commend Google for advancing and innovating in this space. A very good thing. If you remember, innovation in the past rarely came from standards organizations. Either from browser vendors or plugin vendors. It's a very good thing.

Jon: Sounds like the Gears APIs are in WhatWG and then would move to HTML5. My question is whether it is possible to put an Ajax layer on top which uses Gears if there or some other comparable browser features if there instead. Maybe use Flash storage. Is this useful or interesting?

MikeP: I think you are crossing the line between what might be infrastructure and what might be application specific, which might result in standardized APIs. We have talked about widgets within a mashup communication with each other. How would this work when offline? Will Hub work in offline mode?

Chris: Good questions.

MikeP: Maybe get Gears to use dojo.data as its APIs. (inaudible things about MS and synchronization) Questions about what happens when you reconnect.

Chris: Asking the right questions. Not sure anyone has answers, but I want to hear from you.

Jon: Even though we have immediately jumped into evaluatory comments and solutions, I want to emphasize that we hear repeated from Ajax users and developers that offline is one of the top requirements. Maybe faster JS is above it, but still very high up there. Take all of the advantage of the Web, but have the applications continue to work when disconnected. I was at a conference when there was comparison of AIR and Gears and a good number of panelists and audiences said that Gears was taking the right architecture approach of incrementally adding offline to the Web, not trying a new approach like running outside the browser.

Dion: Offline is definitely one of the top feature requests for Google products. But also a psychological barrier which causes a developer to go to another technology like SWING. This knocks down those barriers. We have talked recently how Ajax has exploded into mobile, widgets and desktop, this is another one of those barriers we can knock down.

Jon: The offline requirement comes up in mobile discussion, even though mobile phone tend to be connected most of the time, but not on airplanes for example.

Chris: Gears also improves performance and usability, even outside of offline. Less server communications.

Jon: Yes, workerpools for example.

Dan Appelquist of Vodafone: I wanted to echo Jon's comment about importance of offline on mobile. I take train through a tube each day. Also, lower bandwidths and higher latencies, at least in short term, especially in developing world where usage will be high but infrastructure will be poor.

Chris: Yes, good point about developing world.

Dan: for a lot of people in developing world, mobile phone will be only access to the Web.

Jon: Have you thought about mobile devices and Gears, or only desktop so far?

Chris: No, we are talking with mobile world, also.

Othman: Yes, mobile is important. But mobile distribution is more difficult. Hopefully as desktop browsers are available on mobile, Gears can go there. Right now nothing working on phones yet.

Krishna: On mobile, also have to think about small footprint, battery and other things. Are you looking into these architectural issues.

Chris: I wouldn't say we are doing it now, but it's still in the early phases.

Othman: We chose SQLLite for its suitability for mobile devices.

(inaudible conversation)

Kai (Aplix): My company does Java runtimes. Building bridges from JS to Java. Java can be used for local data.

(inaudible conversation)

Rotan: Java on mobile devices are write-once, where you write-once, then write-once again, etc for every different device.

Jon: One last chance for comments

(someone asks about what we are going to do about this)

Jon: What's going through my mind is that when we do Hub 1.1 we need to keep Gears and offline in mind. I already mentioned Gears in my Hub 1.1 roadmap for Gears or similar offline technology if present, but independent of runtime technology. I was thinking that no difference DIV to DIV, FRAME to FRAME, CLIENT to SERVER, and then CLIENT to OFFLINE. Just another messaging target. But in terms of OpenAjax defining APIs for offline, I haven't heard anything at this meeting indicating momentum around such APIs. Maybe Hub 1.1 implementation might include a bridge to Gears or Dojo offline.

(inaudible conversation)

(Greg Murray says he has a proof of concept about something or other, probably offline)

Howard: Hub APIs need to be independent of implementation for persistence mechanisms. Not a Google Gears persistence but higher-level and independent of Gears. Some of it belongs at level of business logic.

someone: Maybe we should go the other way and evangelize to the Gears team that they should support the OpenAjax Hub APIs

Jon: Not asking much. Just 3 APIs, registerLibrary, publish and subscribe.

Jon: OK, thanks to our special guest.

2:00-2:30 Mashups and widgets

  • Led by David Boloker
  • David will offer a repeat performance of multiple-vendor mashup/widget interoperability work that IBM has done recently and highlight any implications from what his team learned
  • Discussion about possible OpenAjax efforts around mashups and widgets, such as a new task force

Jon: I haven't seen this demo yet from my colleagues at IBM, so this will be a surprise to me. One thing I'll say is that at the wrapup session for AJAXWorld, the panelists were asked what's different now from last year, and the answer from the majority of panelists was "mashups". Some panelists went as far as to say it is the most important thing in computer industry in a long time. So, in Sept 2007, the big buzzword is mashups.

Stew Nicholas, IBM: Most recently working on QEDwiki. Will talk about importance of widgets. What's underway, what we can do with it, some prototyping that been underway.

Stew: widgets, widgets, widgets. we all like them. we like to use each other's. the idea is how to interoperate. Lots of good work at OpenAjax already, seen in InteropFest demos. IDE WG definition of the metadata. Also, security progress is important.

Stew: I took a look back. What we noticed is that with just a little more work to introduce a thin layer to grab widgets from multiple widget repositories. I'll show you some work we have done around Open Search to locate widgets. Using widgets from Programmable Web, Google Gadgets, and StrikeIron. Also, pry loose some of the widgets from Apple desktop. Idea is that these components will co-exist and communicate within the browser frame.

Stew: How to find components? Here is some work we have doing doing around Open Search. The Web is the palette. Multiple repositories outside and inside the firewall. Discovery is done via an Open Search document. Results is an Atom feed, APP actually.

Stew: Goal is to make it as simple as possible. Hub has introduced a good bar, just a couple of hundred lines of code.

Stew: Quick look at what I'm talking about. Programmable Web is a great site run by John Mossar.

Stew: Can take search document and integrate into your browser. Look at widgets provided by the site. Can search based on roles. Let's look for a taxes component. Put it on our palette and make available for our users. Turns out to be a StrikeIron service.

Stew: Another search might be via Google Gadgets. Search for stock chart. Now let me drag out a Google Gadget. With this demo we have added OpenAjax Hub for produce and consume events.

Stew: Last component is an Apple component. Pried out of system library and made into a Web component. The key here is how we browse to it, locate it, put it onto this palette, and used it to aggregate.

Stew: Let's look at Open Search document. It's an Atom feed. The role populates the search list.

Stew: I believe we need a thin layer defined by OpenAjax to enable all of this. You have your PMEs, properties methods events. Some of this is coming from IDE WG. Also, some lifecycle work on how you instantiate controls, such as editing properties for widget.

(question - what are you requesting)

Stew: Yes, a task force and for participation in task force.

Jon: Widget TF or Mashup TF? The whole thing is metadata for widgets.

(inaudible)

Jon: Yes, but the container for the IDE WG is the IDE, where container for this work is a mashup application.

(inaudible)

Jon: Yes, Lori isn't here, but Adobe Dreamweaver and GoLive had those kinds of APIs for custom widgets.

(inaudible)


Coach: Timing is right. Industry needs something like this. Widget becoming most important asset for the Web. Make sense to establish a TF. Likely to overlap with Kevin's work in IDE WG. Probably reuse. jMaki has done related work here also. Don't know exact conclusion, so explore in TF.

Jon: I want to echo what Coach said from process perspective. Always start with TF and then recommend a formal activity.

Jon: SO, yes, separate TF, but I encourage TF to move as quickly as possible so we can make adjustment to IDE if necessary.

Krishna: 3 views. Design, configuration and runtime.

(discussion)

Jon: OK, design is class, configuration is instance.

Larry Lieberman: When I hear term widget or gadget, term is overloaded. One is about consuming web services. Popfly is about so Joe User can put together a number of services to make a result. When I see your demos, I see mini applications.

Stew: Gone through many name changes. plugins commands. But widgets seems to have won the day. To me a widget is a wrapper around a set of APIs, visual or non-visual. Can be as big as a mini application.

Larry: Really good to get some standards discussion in this space. Lots of players. Lots of activity. Question I have. Helpful to engage in a particular set of user problems. Popfly is creating mashups. Suggest that you target on the user. Or is it about standards about metadata.

Stew: Standard on metadata so user can assemble them. Comment on CSS. I have pulled a Google Gadget and an Apple Desktop widget.

(inaudible)

Coach: I want to second Larry's comments. Lots of confusion about terms widgets and gadgets. I have seen different organization use these terms in different ways. There is a fairly well established definition and classification of widget on wikipedia. Can probably just follow them. But don't need to figure this out at this moment. Task force is good approach.

Jon: I agree. I think we are there about making a Task Force. For widget classification, do they have a category for mashup components?

(inaudible - but pretty sure the category was "web widget")

Jon: W3C Widgets is focused on installable desktop widgets

Stew: And focused on packaging. We also need to think about server-side components.

Jon: How about "Web Widget" or "Mashup Widget" TF. The mobile widget and desktop widgets might get mad. They would claim they were there first with the terminology.

(inaudible)

Stew: Will be interested to integrate this with SMash.

Jon: Three names we have mentioned: Mashup Widgets, Web Widgets and Mashlets.

2:30-3:00 - Security Task Force

  • Ajax Security Resources wiki page
  • Collaboration with Interoperability WG on Hub 1.1
  • Access Control feedback to W3C
  • Evangelism activities - how can we get the word out about Security TF better?
  • New activities regarding authentication and server-side security?
  • Process/organizational question - Become a Working Group? Continue as Task Force? Merge into Interop WG?

(slide 2)

Larry Koved, IBM (on phone): Security TF started with use cases. From that we started creating a white paper on ajax and mashup page and resources web page. The white paper has now been published.

Jon: Complete white paper is only on our Web site, the longer version. A shortened version is in AJAXWorld magazine published at the show, also on sys-con online magazine.

Larry: Also another web page that discusses various mashup security approaches.

Larry: When TF started, we talked about various topics we might pursue. We decided to focus on client-side mashups, particularly components from different domains isolated with IFRAMEs. Then IBM researchers developed a prototype called SMash and donated via our sourceforge project.

(slide 3)

Larry: Wrapped up white paper. Now ongoing work with Hub 1.1. Question, are there other security issues. This slide shows some issues we have discussed. How do you authenticate feeds when chained together? What happens if you have federated identity management. If a mobile version, what are the issues? What are security issues with disconnected features, such as Gears. Then trust relationships. Then rights management from publishing side of the world.

(slide 4)

Larry: Shows typical insecure model where portal or proxy is used. Makes content appear to be from same origin, when not. Leaves open bad things, such as CSRF.

(slide 5)

Larry: Another model is single frame with multiple components, which also allows for CSRF. Any comments?

Jon: One thing I'll say is that people understand and like SMash pretty well. The educational and selling job is pretty far along. There is a general interest and hope that we can get it working as soon as possible, is what I am hearing. Anyone want to disagree? Larry wasn't here earlier and missed AJAXWorld.

Larry: That will make Sumeer's job easiest.

(slide 7 and 8)

Larry: Shows problems with access control. Circles represent authentication challenges.

(slide 9)

Larry: Challenge arises with multiple layers. How to propagate back. No way right now. Talking with Sam Ruby about it.

(slide 10)

Larry: Don't know how deep these challenges will be. Probably 2 or 3. Which causes a user experience challenges. Let's say Google and Yahoo, each with a different authentication approach. There is a technique of limited authentication, where someone else can act on your behalf, but only for certain things.

(MikeP - comments that picture shows 3 levels, sometimes more than 3 levels)

Larry: Yes. There is a believability issue if you show a diagram more than 3 deep. Mike would be great for you to help us out. Need some good ideas.

(slide 11)

Sumeer: Quick intro to SMash. Jon said people are generally familiar. I'll go into some aspects and cross-frame messaging.

(slide 12)

Sumeer: Components are isolated. Only way to communicate is through event hub. With SMash, more features than Hub 1.0, such as ports. Wiring of ports is controlled by mashup application, which ensures security. Also some stuff that manages component lifecycle.

(slide 13)

Sumeer: Quick overview. IFRAMEs. Communicate via tunnels. We borrowed this from dojo cross-domain code. We embed a secret when we make a channel and check for secret with each access. We also have a way to detect pfishing attempts.

(slide 14)

Sumeer: Shows layering. You can substitute an alternate messaging mechanism, for example. There is a layer than manages chunking of messages.

Jon: I talked about some of these things with a different picture this morning, but not with as much detail.

Jon: I thought the layering in the SMash code was well done when I looked at it.

(slide 15)

Sumeer: Referring to Jon's roadmap on wiki. Initial discussions on API issues. Talking about dropping room abstraction, for example. Also, talking about authentication and authorization of publishers and subscribers. Instead of just random numbers generated at runtime.

Sumeer: Come up with ideas for next API and then get code working.

Sumeer: One other thing. We could benefit from a higher-level abstraction for components. For example Google Gadgets has an API for pub/sub.

Jon: The previous segment before this was about widgets and QEDwiki efforts to define some standard metadata for mashup widgets. We decided to start an activity about higher-level components.

Sumeer: If Hub 1.1 is too early, we might use cross-frame communications, but later enable cross-gadget communication.

Jon: I don't know whether that should be wrapped into first version or separated out.

(Howard says something)

Jon: With Hub 1.0, you trust everything. But with Hub 1.1 and mashups, it becomes important to put an identity with the component.

Howard: We are talking about communication between trust domains. Maybe gadgets. But it boils down to trust domains.

Sumeer: That makes sense.

?: Pub/sub will be used as access control. Suppose widget finds access control list and therefore can take advantage of it?

Howard: The question was if a widget were to get access control list for another component, then 2nd widget might impersonate the first. But with SMash the top-level component manages the access control lists. The other components can't reach the access control lists. SMash manages this.

Sumeer: Other question is how communication happens between client and server. More integrated with server side.

3:00-3:30 BREAK

Late afternoon 3:30 - 6:00

3:30-4:00 W3C liaison

  • General question is whether we need to adjust our liaison strategy with W3C activities (right now some of us monitor some of the mailing lists, that's it)
  • Specific questions:
    • HTML5 - should we get involved? if so, how?
    • Access Control spec
      • Broadening the attack surface?
      • Plan right now is for Jon to send his own feedback
    • W3C is in process of updating their architecture document and is thinking about how to take Ajax into account

Jon: Beyond W3C. Also ECMA is important. But in mobile it is W3C and OMA. What is our liaison process. We don't liaison formally. Some of us participate on our own. I subscribe to the public lists for WebAPIs and WAFs. Coach is in WAF. I assume Alex subscribes to WebAPIs. So, some of us are monitoring. Occasionally I stir up trouble and send an email. Should we do more? Should we be more proactive and represent Ajax community interests in other standards organizations.

Jon: Two things up right now. Rhys sent question about whether architecture documents at W3C attempt to take into account Ajax. They have reached out and asked. Second thing is Access Control spec. Some people in Ajax community have expressed concerns. I was going to send personal feedback just so that there is some communication, even if imperfect.

Jon: So, what other things should we be doing?

Alex: Is there a process by which we can advocate for things that we need in the specs. Some of the specs are being developed without us. Other constituencies are involved, but not us. Having a process where we could be better represented would be useful.

Ted Goddard (ICEsoft): Besides changing the future of browsers, we can also define how things work in the present.

Jon: Yes, the Ajax layer gives an opportunity to define an API that works OK today but can be implemented better in future browsers.

Alex: But there are things we need from the browser vendors to get headroom. Better library caching. Need a compiler cache for the toolkits. Cross-domain Ajax.

Jon: What kind of mechanism? Task force on browser evangelism.

Alex: I have discussed this with other toolkit developers. One of them suggested we set up a list of things to discuss with browser vendors. Then we vote on them. Then have quarterly calls with the browser vendors and post the minutes. Ask them where they are on our requests.

(inaudible)

Alex: Even if we know that they are being intransigent, we need to know this.

Dan: I wanted to take conversation away from this topic for a second and talk about Mobile Web Initiatives. We focus on best practices, guidelines. If we are writing guidelines for content developers how to write applications. Up until now, web content, and now work on guidelines that address the rich applications inside mobile browsers, ie Ajax. My basic stance - what OpenAjax wants to get out of liaison, a mechanism to ensure no double work. At W3C, there is a Hypertext Coordination Working Group. We have had an OMA representative. Maybe have an OpenAjax person in HCG, just to have visibility.

Rhys: As well as a kind of general coordination, there are a number of specific items. For example, access to device APIs, UWA WG is doing this. How many people are aware that W3C has produced a document Architecture of the World Wide Web? From about 3 years, says some things about URIs, pre-Ajax, pre semantic Web. Needs revision. TAG at W3C is looking at it. Wants some advice on that. For example, searchability discussion about URI storing application state.

Howard: I wanted to take first part of Alex's statement. First, make a list, given to browser vendors. Having a list is the first step. We need to know what we want. Without knowing what we want, we will never get it.

Jon: Question is where does it happen and how. Most important that it happens, but someone has to host wiki or irc or whatever.

Alex: PR pushes out announcements. OpenAjax could take it on, but could happen outside anyway.

Jon: Someone needs to make a proposal and then let the industry react.

Coach: We have been talked about lobbying the browser for quite a while. CommHub, Interop, Marketing, but all different aspects. So far no one has taken the lead. Fits mission of OpenAjax mission. I propose within OpenAjax a lobbying task force, job is to gather lists and publish and thereby apply some pressure to browser vendors.

Jon: So, we could propose a TF and see if we get critical mass. Then later maybe a WG, which gives weight of formality of OpenAjax Alliance making a formal statement. But first step is to write up a task force and see if people show up to the meetings.

Jon: We need someone to be the organizer, the chair of the task force. Someone has to lead, even if deferring on the lead, but has to lead the process.

Coach: I'll do it.

Jon: As usual, at most one volunteer. OK, that's our 4th task forces that we formed today.

Jon: Let's get onto other issues, the liaison. Liaison is good. Communications is good. But who is going to do it. I could do some of this, but priorities and bandwidth, so I haven't done it yet.

Rhys: One thing is general, such as you becoming liaison on HCG. Also, specific, UWA to our Mobile TF is accomplished by shared membership.

Jon: On an informal basis, try to get overlapping membership is good. But who will volunteer to do that role. Looking around, everyone is bowing and ducking.

Rhys: The main motivator is when people have a specific job-related interest.

Jon: I don't think we have made any progress except that we need to do liaison and need to get people to do it. That's mainly focused on W3C. Then there is the ECMA activity and ECMAScript4. ECMAScript and JavaScript are important to Ajax. Do we want to include JavaScript itself as something we include in our lists.

(inaudible)

Jon: Let's close this issue. The runtime task force can decide whether to take a lead on ECMAScript advocacy.

Dan: I want to re-iterate that OpenAjax needs to think of MWI in a different light. Not producing standards, but guidelines for using existing standards.

Jon: We have talked about doing Best Practices. Need to avoid overlap with W3C MWI BP. Also, we have OpenAjax Conformance trust brand and W3C has Mobile OK trust brand and avoid overlap there.

4:00-5:00 - Mobile Task Force

  • White paper status and next steps
  • Mobile Device APIs status and next steps
  • Other activities we should pursue in the short-term?
  • Reminder: W3C/OpenAjax Workshop on Mobile Ajax happens the next day

Rhys Lewis: I wanted to go over where we are and then go to questions. The two things we decided back in NY in March were a white paper on Mobile Ajax and work on sorts of APIs that we might want to provide to allow access to devices. We have an outline of white paper. It will say that it is possible to do Ajax on mobile and here is how to do it. Dan has been giving presentations that showcase this. There is a message that on some browsers it is good enough already. In mobile environment you don't need all of dojo to do something useful. Any comments or questions on white paper?

Jon: Ajit has produced a nice white paper on the current state of Mobile Web and Mobile Ajax. Have you seen that?

Rhys: No.

Jon: We need to be careful about overlapping another white paper. I think we are talking about focusing on developer techniques. We could reference his overview but our white paper should focus on what developers should do.

Rhys: W3C is pushing device independence, now calling it ubiquitous web, recent renaming. Elements of overlap of certain kinds of Ajax-enabled sites. UWA is developing a markup language based on XHTML, but gets adapted to different devices, Windows Mobile, Symbian, etc. That has implications for how Ajax markup works. Original markup may be different than what runs on the device.

(inaudible)

Rhys: There are workable solutions in place today. Doesn't negate what you are saying. Better to get increased compatibility. But there is an ecosystem that works today.

Jon: I expect the white paper will touch on server-side adaptation. We haven't discussed this yet, but I bet we can agree on at least some words in that area.

Larry: White paper should also talk about leveraging the better things that exist on particular platforms.

Rhys: Absolutely. What you see is just a brain dump of things we might say.

(someone mentions power management)

Jon: Iterative process. One problem we might have too many cooks on the white paper. We need someone to keep us all organized.


Jon: One more issue is that this white paper is likely to be out of date quickly and will need revision. Different than our other white papers.

Jon: My sense of target audience is web developer thinking about getting his web applications working on mobile devices.

Dan: That's one potential. Another is mobile application developers who are considering Ajax versus platform frameworks.

Dan: Some people think Mobile Ajax means a subset

Rhys: I think Ajax is Ajax, but you aren't going to get full toolkits running on today's devices, but some subsets of existing libraries. Ajax approach works, but may need subsetted libraries.

(Four people volunteer for contributing to white paper)

(Rick Saletta volunteers to be editor)

Rhys: Next topic is providing JavaScript APIs to device capabilities

Rhys: We looked at the kinds of APIs we might need. We put together a wiki page which is a survey. Things going on at W3C. Most interesting thing was JSR248, an amalgam of 8 or 10 other JSRs. They give Java bindings. They are starting to ship. Could we produce JavaScript alternatives, and then on some platforms go through Java, other platforms go through Windows Mobile, etc. These bindings have been approved by an industry body. Of great interest to UWA WG at W3C.

Rhys: APIs like location, contact list, if you know any good APIs, tell us, otherwise we will latch on Java

(MS says there are Windows Mobile APIs)

Rhys: Is there a URI that we point to from our wiki page?

(inaudible - about OMA having APIs)

Rhys: I'm not aware of anything in this area at OMA. Nokia is big in OMA and hosted the JSR248 effort.

(question about whether Java APIs are encumbered)

Rhys: Not using their APIs, but instead just as exemplars.

(someone mentions Opera APIs)

(someone mentions security concerns)

Rhys: There are ways to ask people without bombarding them with continual questions. Things at EU and things at W3C.

Jon: One question is how much OpenAjax can bite off. The Java APIs were tough standards work, took a long time. Are we able to attempt a similar effort to achieve JavaScript APIs.

Rhys: Good question for Task Force after completing analysis work. If just accept Aplix, maybe we are basically done, but may not be acceptable via a consensus process.

Jon: Maybe we should try guerilla tactics of leading with open source where we get some code working on some platforms first before pushing a spec too much.

(inaudible - about how to get adoption - Dan )

Jon:Define standard messages for a subset of what exists in JSR248.

Rhys: Low-hanging fruit APIs.

Jon: Note that position papers for tomorrow is that there is a lot of interest in device APIs. So we should look at how to provide high value at low cost

Rhys: Most of our desired APIs are already available from OS.

Jon: We could use Hub as platform independent messaging scheme which platform vendors could support via bridges to their own APIs. Allows for incremental approach. We have to address security issues with Hub already (theoretically).

Rhys: Final reminder - Mobile Ajax Workshop is tomorrow. How many are coming (about 12 raise their hands)

5:00-6:00 Marketing WG

  • OpenAjax Conformance 1.0
    • Previously discussed definition of OpenAjax Conformance 1.0: support conformance requirements in OpenAjax Hub 1.0 specification
  • White papers
    • Mobile Ajax white paper
    • Other white papers? (JSF+Ajax, portals+Ajax)
  • Progress on demos
    • InteropFest applications
    • Product selector application still a dream in Jon's eyes
  • What other new promotional activities should we pursue

Jon: For OpenAjax Conformance, should we define a version labeled 1.0 which means that to be conformant you have to honor the 5 conformance criteria in the Hub 1.0 spec. I don't remember the five requirements, but one is you must call registerLibrary(). You must have a multiple usage strategy so if two components on a page using your library, you have to some sort of approach for addressing that requirement. Do we want go through the effort of labeling it and announcing it, or say we'll do it later.

(inaudible)

Jon: I think it's a lightweight thing. Just update one of our Web pages. The industry can choose to embrace or ignore it. Could just do it, but decide how much we push it and evangelize it.

(inaudible - Mike)

Jon: Coach, what do you think, you are on committee and have a toolkit

(inaudible - Coach says something about having achieved critical mass and the need)

Jon: Kai, are you catching this? Howard, Mike and Coach said yes we should go forward

Rick: How much of a problem will this be if people start claiming conformance? Will it be a big burden to support?

Jon: If people jump on it, then we would shout halleliuiah. We don't have a compliance test suite. Best thing we have is InteropFest. The test suite is just to test our our implementation of the Hub spec.

(inaudible - what is definition of OpenAjax Conformance)

Jon: It would just say that you have to meet the conformance requirements from the Hub 1.0 spec

Jon: I think Howard and Rick are pointing out opposite sides. Rick says that if we go forward, people might make inaccurate claims for various reasons and we might need to take action. But the other side is that people are already making claims of OpenAjax Conformance without there being a definition. People want to claim OpenAjax Conformance but we haven't told them what it means. Then there is this issue of an ideal thing we would like to do, such as a full conformance test suite, but we are a lightweight organization, and who is going to do all of this work.

(inaudible - David Boloker talks about how we decided to just go with conformance not compliance)

Jon: Regarding press, I have found it doesn't take much time. They don't want to use up much time themselves. Usually, the guys in the press just want to report accurate information and don't have an agenda to do bad things. If you give them some information such as a press release, they ask a couple of questions, and then they publish an article that to the best of their ability to publish a nice article. That's the way it has been so far.

(more inaudible)

Jon: It sounds like the most important thing is to have a plan for various things that might happen. That's what I'm hearing. That's Rick point. Especially since Rick has volunteered to take an active role in the conformance rollout.

ACTION: Howard, Coach, Matt are going to clarify conformance requirements and be aware of the possible consequences

Jon: Next topic. White papers. Already talked about Mobile Ajax white paper. A few months ago a lot of requests for JSF for Ajax and portals for Ajax. The overall question - what other white papers.

(inaudible - Erwan or Ric?)

Jon: Book has come out on Ajax with JSF. Maybe that satisfied people's needs.

(inaudible)

Jon: I was thinking of something like security white paper which gives high level overview. I am hearing some people willing to volunteer. Ric Smith has sent papers on subject. I think we have clearance on posting them. We have starting point, which is helpful. Anyone want to take the lead.

Erwan: I will.

Jon: OK, go write it!

ACTION: Erawn Paccard volunteered to work/lead on the JSF+Ajax portals whitepaper

Jon: Next topic: demos. With InteropFest, at least we have content. I believe that people looked at each other's work and learned from it. I actually took ideas from DWR demo which used OpenAjax Hub. I think that having actual content that works is highly valuable. But any suggestions about how to proceed?

(inaudible)

Jon: I'm not hearing major ideas regarding demos.

Jon: Last topic is what we should be doing to get message out? We are doing press releases, going to conferences, and other things. Should we be doing anything else?

(nothing)

Jon: OK, we are done! Thanks you everyone, and thanks to Microsoft for doing such a great job hosting our meeting.

Retrieved from "/member/wiki/2007_September_Members_Meeting_Minutes"
Personal tools