2008 October Members Meeting Minutes

From MemberWiki

Jump to: navigation, search

Contents

Wiki pages for the OpenAjax members meeting of October 23, 2008

The following are the various wiki pages that document the OpenAjax Alliance's members meeting of October 23, 2008:

Attendees

In person

  • Eduardo Abe, ILOG
  • Ruhul Alam, Vignette
  • Alessandro Alinone, Lightstreamer
  • Anees Ansari, Microsoft
  • Kin Blas, Adobe
  • David Boloker, IBM
  • Jeremy Chone, Nexaweb
  • Jon Ferraiolo, IBM
  • Bjorn Freeman-Benson, Eclipse Foundation
  • Kevin Hakman, Aptana (afternoon)
  • Bertrand Le Roy, Microsoft
  • Rama Gurram, SAP
  • Jennifer ???, SAP
  • Scott Richards, Adobe (Dreamweaver)
  • Chris Schalk, Google (morning)
  • Marc Silbey, Microsoft
  • Simon Walmsley, Lightstreamer
  • Coach Wei, Nexaweb
  • Howard Weingram, TIBCO

On phone

  • Phil Berkland, IBM
  • Lori Hylan-Cho, Aptana
  • Javier Pedemonte, IBM

Minutes

Welcome

(Scribe: Jon Ferraiolo)

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slides 1-4)

(Everyone introduces themselves)

(Jon repeats news from recent to blog entry, /blog/?p=66, about Steering Committee election)

Summary of activities during past several months

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slides 5-10)

(Jon goes through intro slides from F2F slide deck that talk about what OpenAjax has done in last 6-7 months)

(Regarding browser wishlist)

Jon: It turned out to be more successful than we had thought. Coach and I were experimenting and did everything on the cheap. I have received many compliments in the past couple of months.

Bertrand: How about refreshing the wishlist?

Jon: I wasn't planning on it any time soon.

Marc: The list has been very helpful to the IE team.

Howard: How about refreshing it next year?

Jon: I have been resistant because it took some time and there are other things we have to finish. But now that I think about it, we cn reuse the same tools, so maybe it isn't that much work.

Howard: Good to get browser teams actively involved.

Bertrand: Is there any information about IE cycles?

Marc: As evidenced by the significant investment in IE8 from both a features and platform standpoint (e.g., stds, compat , jscript, etc.), we are committed to the IE platform beyond IE8. Beyond that, we’re not commenting on possible dates, features, versions, etc.

Jeremy: Is JavaScript 1.5 on the wishlist? Do people care?

Jon: I don't actually now what's in JavaScript 1.5. I can say that no one asked for ECMA4 until it was added as one of last features at the very end of the cycle.

Bertrand: Most of the features are about fixing problems in JavaScript.

Working Group Charters

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slides 11-11)

Jon: The charters for our 3 working groups expire at the end of the year. Because of inactivity with the Marketing WG, I propose that we do not renew it and instead rely on the Steering Committee to manage marketing activities and that we push a marketing requirement into the technical working groups. Move Conformance into Interop WG, which is where most of the discussion was happening anyway. The Steering Committee talked about this last week and they thought this was the right direction. I propose extending the Interop WG and IDE WG by one year each to finish up Metadata, Hub 1.1, Registry, and Conformance. Maybe create a Mashup or Gadgets WG to finish mashable widgets, pending discussion later today. Maybe create a Mobile WG and a Security WG if we come up with a deliverable that those groups would create.

Howard, David, Coach: +1

Jon: Any objections?

(silence)

2008 InteropFest

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slides 12-15)

OpenAjax open source implementation

(Jon starts off by highlighting the many features that are implemented within the open source mashup tool found at /2008_InteropFest/mashupapp. Contains implementations of Hub 1.1, the widget and mashup parts of OpenAjax Metadata, adapter technology for Google Gadgets, and an interactive widget repository that supports OpenSearch. Help system. Ability to upload contributed widgets. Property editors on the widgets. Fixed layout or flow layout. About 20 sample widgets of various types.)

Javier: There are widgets that use Dojo, YUI and ExtJS.

Jon: And a Google Map widget.

Adobe Dreamweaver

Scott: Would be nice to have a web service for widgets

Jon: Yes, once we have a collection of production ready widgets, we should set up an official repository.

?: Need a standard for a web service to find widgets

Howard or Jon: OpenSearch looks good. That's what we have implemented in our reference implementation. Haven't seen any shortcomings yet.

Kin: Any plans to offer translation services for messages?

Jon: Not translation, but instead looking to define a small number of standard topics and payloads

Howard: Standardization is a good strategy initially.

Howard: How about a topic Registry?

Jon: Actually, I have been thinking along that line. Later on today, I will be proposing that we transform the OpenAjax Registry into more of a self-service, public web-based system versus the more heavyweight process we are considering now. We could have a similar self-service, public system for a topic registry.

Jeremy: How does wiring happen? (referring to inter-widget message wiring)

Howard: Could happen at design time or runtime.

(Scott demonstrates the Dreamweaver Web Widget Packager that imports an OpenAjax OAM file, pulls in dependency files, and then runs through a process to convert them into Dreamweaver extensions such that they appear within Dreamweaver widget palettes. Will hook up to an OpenAjax Metadata validator web service at the OpenAjax site once that is available.)

Scott: Dreamweaver is highly extensible and uses HTML and JavaScript for much of its own UI.

Scott: Web Widget Packager is available in beta form on Adobe Labs. Has documentation of the widget format. We added a couple of dw: extensions to OpenAjax Metadata. On Adobe Exchange, on the Web Widget category, there are some widgets.


Scott: Worked with widgets from YUI and jQuery and BatVision on top of MooTools.

Scott: Replaces @@id@@ as part of its processing

Scott: Have worked with Ken Burns with his slideshow widget, PhatFarm MultBox, rounded-rect widget, image viewer.

Scott: Can pull off of the Web. We have a MSP format, like ZIP

(lots of positive comments from the audience)

Scott: Can use Flash using a JavaScript wrapper

Jeremy: What about widget preview

Scott: We show an icon

Jeremy: Something that shows its actual size

Jon: In reference implementation we have a feature where you can preview the widget within a popup before putting it onto the canvas

Howard: In some case, there might be a problem in seeing the widget if you haven't purchased it yet

Howard: Do you support IFRAMEs?

Scott: No

Howard: So, just for developers?

Soctt: Right

Howard: Any wiring?

Kin: No, but it is on our list of things to look at. But our audience is mainly designers, people who know some JavaScript but usually aren't experts.

Howard: Are you thinking about saving as OAM?

Scott: Have thought about it. Would be nice if you could turn a snippet of content into a widget. Build a page and save part of it as a widget.

Kin: Hard to do now because it's the wild west, everyone does things in their own way. There are different approaches for different widgets.

Eclipse and Rational demos

(Phil Berkland demonstrates code assist in Eclipse using the OAM JavaScript API support that he added to JSDT. Also demonstrates OAM widget support in Rational Application Developer. Shows YAHOO.widget.Panel will code completion and help documentatation. Took XML file for Yahoo toolkit generated from OpenAjax's open source project.)

Phil: JSDT features will be in Eclipse 3.0.3. Just locked down now and will ship in a month. Rational will include the JSDT features plus the widget metadata support.

Phil: Widget palette contains some OAM widgets created by IBM. Not WYSIWYG visual design, but adds snippets of HTML into the document.

Chris: Do you need to buy Rational to get the features or can you just add plugins to the free Eclipse?

Phil: JSDT is a standard part of Eclipse. The widget features will be available only in the Rational product.

Howard: Timeframe?

Phil: JSDT is building now, will be available in a month.

(Scribe: Ruhul Alam)

SAP Research Prototype Demo - BijouX Client

(Rama Gurram demos a mashup editor under development at SAP)

  • Mash up tool for enterprise
  • EMAP Architecture and Design: Components - Diagram
  • CRM Scenario, Sales person exploring possibilities
  • Can import Google gadgets via URL
  • Can import OpenAJAX gadget via file and URL
  • Layer on top of Google via handler to connect to OpenAJAX hub events
  • Can create desktop "Saplet" that is a wrapper around IE engine
  • Support for W3C widget (Mobile support)
  • Offline versus online desktop widgets - IE has .hta support
  • SSO and secure events - discussion for 1.1 (security versus convenience)
  • Widget/Gadget are overloaded terms - needs to be defined in Wiki terminology
  • REST API to get Google gadgets? OpenSearch?
  • Currently built on OpenAjax Hub 1.0, uses IFRAMEs, does cross-frame messaging using Flash
  • Widget repository for BI, CRM, content management widgets
  • Event hub debugger
  • Can install widgets onto Windows desktop

Lightstreamer Demo

  • COMET based push server providing real time updates
  • JSDoc converted to OpenAJAX Metadata (internally using Perl based, support for JS based)
  • JSDoc plug-in

iLog Demo

  • JSF Components into Mashup applications
  • XML metadata is from the server, not available via client
  • Collected info on how to build server based widget, should go to Working Group
  • WAR file on TomCat + Demo license should be runnable by anyone

(Scribe: Bertrand Le Roy)

Hub 1.1 and mashable widgets

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slides 17-25)

Jon. Scope parameter: when using hub 1.1 you have a class that is the implementation of the widget. You have to let a class be instantiated so when a callback comes you want that object top be that class. There is a scope parameter in 1.0 not in 1.1. General question is there were things in 1.0 that we don't have in 1.1. We need to look through those.

Q: Do we need to take care of how the widget communicates with the server?

A: no, only on the client-side.

Q: then what is server-side widgets about?

A: It's for widgets that need interaction with the server to work. Is there work we need to do, APIs to provide? We think we don't but need to check.

Jon: common question is about standardizing events. We should try to look at a small number.

Howard: provide examples but more generally provide a way to register standard events so the community does the work.

Jon: one of the topics is registry, and I want to propose this becomes a self-service thing. It is useful as an information source. We should make it as easy as possible to put data in there. Make that a public wiki where people can populate their own entries. In the same way as global objects, events and payload could be published there.

Howard: let's not be the gatekeepers. Events use the reverse dns conventions so we shouldn't have to control that. We shouldn't be policemen.

Jon: majority of payloads will be JSON because it's so convenient.

Howard: we should have searchability and RSS feeds for all that stuff. Also basic building blocks for the events and payloads.

Jon: requiring login and authentication. I propose we don't look at this now. We'll look at single sign-on in the security task force.

Q (Adobe): is this about the keys that for example Flickr would ask?

Jon: yes. This is one approach.

B: application authentication vs. user auth.

Howard: yes, there needs to be a proxy of sorts for app auth.

Jon: reconciliation with Google gadgets RPC. I'll have some slides about that. That's what Chris is here for. How to package? 1.1 is substantially bigger than 1.0 (~50kB vs. 3kB) There is a need for the smaller subset in the industry. We need to show people how you can write a security manager. A ref implementation and/or white papers seems in order. Should it be hub 2.0 considering how much bigger it is. We will need to explain how this used to be 1.1.

H: Postponing the client-server feature.

Jon: there have been strong claims from Alex that we shouldn't do it ever.

H: Right now completely unspecified. api spec must specify error conditions. In 2.0 we 're doing security, so not comfortable with letting errors bubble. There is also the question of container such as smash that isn't standardized and needs custom wrappers to use different types of providers. We should have additional apis to apply a standard to these interface. Must also remember most of our users are not going to be experts in order to not end up with a lot of insecure mashups out there.

Jon: various reviews we have to do to make sure existing industry products needs are begin addressed. On security front we need to review. Timeout may be too unforgiving. We also need to check performance and the spec has to be completed. We should have interop calls once a week and work on these issues as a fast process to drive completion during 2009. We should investigate how to reconcile with Google technologies. Lots of overlap between Google and OpenAjax. We are supporting controls from libraries and mini-applications like Google gadgets. Technologically, the overlap is big enough that we should consider unifying. We do host Google gadgets today though. Do we have a Shindig server? No. We use Google sandbox.

G: planning on using Shindig?

J: we would if we had to. Shindig is the reference implementation of OpenSocial. PHP and Java versions. Features shared: reliance on server (but small), gadgets can be url or html snippet, RPC pub/sub API, properties with property editor dialog, etc. Having two different specs doesn't help. Significant part of the people I talked to wants us to "unify". Standalone widgets are already being used in shipped products such as Dreamweaver. Proposal is to separate mashable widgets into a different spec.

Q: it seems like everybody here is interested in runtime scenarios.

K: configuring is one thing, author time editing for setting the defaults is another. In the ide metadata specs we try to distinguish between the two. In terms of runtime context, we have VS, Aptana, Adobe who show a strong interest in the authoring part.

Jon: for gadget stuff: mashable, adjustdimension, get/set properties, etc. would move to the separate spec. To reconcile, mashable widgets spec could be modified. Google could enhance its support to include enterprise features. For remaining differences, we can namespace extensions.

Google: being open-source, we can get people to participate into the spec.

Jon: adding support for Shindig shouldn't be too difficult. We should have better support for gadgets in ref implementation.

(Scribe: Howard Weingram)

OpenAjax Metadata

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slides 27-28)

DECISIONS

  • Jon: don’t rename IDE metadata à OA IDE Metadata. Leave it as OAM.

PROPOSALS

  • KH: proposes conference between concerned toolkit vendors (e.g. Aptana, MSFT, ADBE, jquery) to try to organize this.

DETAILS

  • Kevin summarized goals &c (see slides)
  • API style + markup style specs
  • Kevin thanked Microsoft for its contributions
  • Dominated by IDE vendors with some contribution from mashable gadgets gang
  • Very close to finalizing
  • JF: main thing is that we need to finish the spec

o Details
o Issues are coming up as people implement
o Phil showed JSDT use with Eclipse

  • KH: Scriptdoc and jsdoc libraries are important
  • KH: Getting the word out to developers and community is the biggest challenge going forward
  • Bertrand: current studio: everything relies on own format but in next version, OA Metadata is in the works. Can’t talk about dates.

o On library side, will publish our metadata in OA format very soon

  • Bertrand: there is a very, very strong need for this metadata.

o Community needs this so much that random community members are willing to provide this metadata o People are providing this kind of metadata

  • KH: proposes conference between concerned toolkit vendors (e.g. Aptana, MSFT, ADBE, jquery) to try to organize this.
  • Jon: don’t rename IDE metadata à OA IDE Metadata. Leave it as OAM.
  • See slide for list of tasks.

OpenAjax Registry and OpenAjax Conformance

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slide 29)

DECISIONS

  • Turn registry into self-service utility with a web service

PROPOSALS

  • Chris suggested using Google AppEngine. JF: if needed.

DETAILS

  • Chris Schalk asked for background & summary of registry. Jon explained it.
  • JF: industry is getting better now. Most Ajax libs now moving toward namespaces, so less needed.
  • JF: This is a lower priority than hub 1.1

(Scribe: Rama Gurram)

WebSandbox Presentation (By Bertrand)

http://websandbox.livelabs.com/

  • WebSandbox is cross-browser JavaScript virtualization layer that provides a secure standards-based programming model without requiring any add-ons
  • Showed simple Clock Example (where one widget try to access other widget) using WebSandbox
  • kevin: How do you know what is inside widget A vs Wdiget B?
  • Jeremy Chon: Rewriting of JS happens on Serverside or Client side?
    • Answer: both.
  • David: Sandbox is On server?
  • Jon: In terms of technology - Are we Sandboxing JS, Sandboxing DOM, CSS?
  • Kevin: Does it work on IE7, IE 8 DOM
    • Answer - yes
  • Works on IE, Chrome, Firefox
  • David: Is the Client or Server Open Sourced?
    • Answer - All of it is opensource

Mobile Ajax Presentation (By Jon)

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slides 31-34)

Key Points:

  • "Write-once,run-anywhere" proposition across a wide range of mobile devices
  • Published White papers
  • Mobile Ajax API
  • Showed Bondi Architecture for Mobile Ahax API
  • Based on ploicy, web sites can access API

Discussion:

  • kevin: Do we publish OAA Guidelines?
  • Jon: OAA prefers simpler javascript API
  • Jeremy: It is better to normalize API across desktop, mobile devices
  • Jeremy: "Design-Once, Run-anywhere" better describe the Mobile Ajax
  • Jon: Write-twice (one for desktop, one for mobile) , Run-anywhere might makes sense
  • Howard: If you can write once for few devices which has similar form factor it is good enough.
  • Jeremy: Write-once,run-anywhere is failure! (e.g., J2ME)
  • David: We need a better marketing term for "Write-once,run-anywhere"
  • David: How WORA (?) works across different browsers?
  • Jeremy: We have to be honest about what we can or can't do with Mobile Ajax
  • Jon: In Mobile world the browsers are little different. In Desktop world Ajax libs hide the browser differences, but this is not true in the case now Mobile browsers. We need get Mobile borwser as same ball park as of desktop browsers.
  • David: Do We need provode the functionality that will enable create mobile apps that rund on all mobile browsers.
  • David: What is long term vision - We need to define it.
  • Howard: We need to define basic requirements?
  • Jon: Creating MobileAjax Wishlist is our next step.
  • Jeremy: Apect 1. Bringing mobile browsers par with desktop browsers. Aspect 2. ??? Mobile Apps learn from Desktop Apps
  • Kevin: Device emulation, test tools is the key (eg. Aptana has done for iphone)

Single sign-on and mashup authorization

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slides 35-35, and /slidedecks/OpenID-OAuth-for-OAA-20081023.pdf)

  • Authentication, Access Control
  • Givivg/Limiting access rights to intermediary (limited delegation)
  • OpenID, OpenAuth - are good candidates to address SSO, delegation
  • OpenID: Meant for Identity (Who are you?): Verisign, Yahoo has OpenID servers. Works with current browsers, so no additional support needed. Extensible
  • Bertrand: Any body can be a OpenID provider.
  • OAuth: For allowing who can do what
  • Both OpenID, OAuth hides the usrs info
  • Jon: Both OpenID, oAuth are good candidates OpenAjax Security needs
  • David / Jon: In case of OpenID two different IDs required for both external and internal widgets.
  • Jon: Idea is to start th security sepc that can be used in OpenAjax Projects

WrapUp & Future

(Slides: /slidedecks/OpenAjax-F2F-20081023.pdf, slide 36)

  • To finish Metadata, Hub, Registry, optionally SSO, MobileAjax Readiness

David: Initiative around on SSO is important as everybody is interested in SSO

Jeremy: Is Mobile Ajax possible with out right mobile partners?

Retrieved from "/member/wiki/2008_October_Members_Meeting_Minutes"