Interoperability Minutes 2008-03-05
From MemberWiki
Full minutes: /member/wiki/Interoperability_Minutes_2008-03-05
Contents |
OpenAjax Alliance Interoperability Committee meeting minutes 2008-03-05
Attendees
- Jon Ferraiolo, IBM
- Stewart Nickolas, IBM
- Ted Thibodeau, OpenLink SW
- Bertrand Le Roy, Microsoft
- Adam Peller, IBM
- Simone Fabiano, Lightstreamer
- Rich Thompson, IBM
- Javier Pedemonte, IBM
- Kin Blas, Adobe
Original Agenda
- Agenda
- OpenAjax Hub 1.1 discussion
- OpenAjax Hub 1.1 and OpenAjax Metadata proposed schedule
- OpenAjax Registry
- Relocation conformance requirement
- Add CSS styles (i.e., class names) to Registry?
- Add instance attributes (per Lightstreamer) to Registry?
- Reminder: register for face-to-face meeting: March 21 in NYC
Minutes
Hub 1.1
Jon: Let's walk through the new spec pages on the hub 1.1 managed hub feature. This is a first run-through today. We'll go through this again in more detail at the F2F.
(Jon explains how the approaches taken with the current spec and current open source for Hub 1.1 was largely informed by the approaches advocated by the Communications Hub Task Force, where there are connection handles and plugin providers.)
(Jon explains introductory sections, which sets the stage for user-built mashups, as a setup for the security issues. Finally, we look at the 4th picture, which shows the 12 steps in setting up a mashup with widgets and how one widget publishes through the managed hub and another widget received the event.)
Jon: Javier, does the picture provide an actual conceptual overview for what exists today in the open source?
Javier: It is spot on.
Jon: This is a conceptual overview. Under the hood, it doesn't work exactly like that. For example, with connHandle.publish(), the connHandle is actually a direct link to the provider, bypassing any of the Hub 1.1 JavaScript. But I think the conceptual overview show be as it is because from a developer perspective, connHandle.publish() is an API that we define in the Hub 1.1, so it looks like a Hub 1.1 API to them.
Javier: Makes sense.
Jon: Any other comments or questions on the picture?
(none)
Jon: Let's look at the next section, which shows some source code. The first snippet shows how the mashup container application looks. This again is a conceptual overview. There is a note in the text that talks about how the example shows hardcoded calls to inline.load() for one widget and smash.load() for the other widgets, whereas a table-driven approach is more likely in practice. Given that, how does this snippet look?
Javier: The code now uses something different than smash.load. I'll look to see what it does and fix the example.
Jon: Now let's look at the sample source code for the widget. The example aligns with the latest OpenAjax Metadata spec. As that spec evolves, this snippet will need to be updated. Notice that the example does not show loading of the OpenAjax JavaScript or the providers. The assumption is that the mashup application is doing that on behalf of the widget. Stew, does this look right?
Stew: Looks fine from an overview perspective. We will get all of this working in the open source project soon.
Jon: Now let's look at the providers. We are proposing two built-in providers, a smash provider and an inline provider. The smash one delivers security, using IFRAMEs. The inline one is for trusted components and uses DIVs. There is a facility for custom providers that are supplied by others or in the future by OpenAjax. For example, maybe there will be a future provider that leverages HTML5 cross-frame messaging as a faster replacement for the smash provider. Also, maybe one for Google Gears or Java applets. The providers can be specific to a particular version of a particular browser. For example, if one browser supports HTML5 messaging, then the mashup could use that provider only for a particular browser and use smash for other browsers.
Bertrand: Must it use IFRAMEs for security?
Jon: No. That's up to the provider. The smash provider uses IFRAMEs, but other providers can use a different approach. What do you have in mind?
Bertrand: For example, the <module> proposal, or perhaps some internal MS technologies. Seems that IFRAME is a temporary option until something better comes along.
Jon: I agree with that. In fact, that's one of the reasons for the current architecture.
Javier: Yes, we are trying to build the open source to allow for different communications providers such that they can use IFRAMEs or other approaches
Jon: Let's jump to the next chapter, on APIs. You'll see that the mashup container calls createManagedHub, which returns a hub instance. This means that you can have more than one managed hub in the same mashup, where say 3 widgets are in one managed hub and another 4 widgets are in a different one. The managed hubs are independent. Not sure how often a mashup would use more than one managed hub instance, but it fell out of the design, so it's there.
Jon: Notice the connHandle APIs. The widget calls connect to connect to its parent, and then calls publish and subscribe on the connection handle. That way, the underlying system can manage which widget is sending which message and asking to receive which topics. Any questions?
(none)
Jon: Javier, can you talk about configureProvider() and bind()?
Javier: configureProvider() passes parameters to a provider. If you have multiple managed hubs, bind() assigns a widget to a particular managed hub instance.
Jon: Is bind() only on the manager side?
Javier: yes
Jon: Any questions on this chapter?
(none)
Jon: Let's look at the providers chapter, which also talks about SPIs. Just like the Communication Hub TF discussion, providers hook into via an SPI.
Javier: Our goal was to make it easier for regular developers. We put more burden on the provider developers.
Jon: In preparation for our face-to-face, any suggestions for what sorts of additional things or improvements we can make so that all of this Hub 1.1 information is more understandable?
Bertrand: Tutorial. How to build something. How to build the app. How to build a widget. How to build a provider.
Kin: More code samples. Also, more diagrams. Explain how the Hub's global functions related to the managed hub.
Proposed schedule
Jon: I am proposing that we have an interop event starting in the summer and culminating with a trade show in September or October. Then finish Hub 1.1 and OpenAjax Metadata in the fall. Any feedback? Is this too long of a time period? I was thinking that we have to wait until September for the interop event because of summer vacations. Any comments? Bertrand, you have been a proponent of an IDE interoperability event.
Bertrand: No comment so far.
Registry relocation requirement
Jon: Bertrand sent email saying that the relocation conformance requirement works reasonably well with globals but will be more impractical for extensions to core javascript and HTML elements.
Bertrand: Maybe OK as a requirement, but only a few toolkits will support this requirement. That's fine. But also too tied to jQuery. Maybe reformulate the requirement.
Jon: I should mention that the title of the requirement just says "must relocate" but the text of the requirement say either relocatable or "disable-able". Would it be enough to just change the title?
Bertrand: That would be OK.
Bertrand: But also ties to levels of conformance.
Jon: Yes. I will write up a proposal for conformance levels and send through email for discussion, and then we'll see if we can resolve at the f2f
Jon: For now, I'll make the minor change to the title for the relocatable requirement, but there may be more changes due to our conformance discussion.
CSS classnames and HTML attributes
Jon: CSS classnames - add this to the registry?
Bertrand: Should be consistent with how we treat globals. prefix* is reasonable to approve. If it is not consistent with its prefix, then acknowledge.
Jon: I think we should add one or two fields to the registry for css classnames.
Bertrand: yes
Jon: Doesn't Dojo have good behavior with CSS classnames, where everything begins with dojo* or dijit*?
Adam: Not sure. Sounds like a good idea, perhaps more important for interoperability than JavaScript globals. There is a compatibility issue, though, so I'm not sure it is manageable.
Jon: Let's talk about HTML attributes. Simone sent email that says Lightstreamer adds a few attributes to HTML elements. Dojo adds some attributes too such as dojoType. My opinion is that we should add these to the registry just like the css classnames.
Adam: Same compatibility questions as with classnames.
Jon: Yes. I'll send email with a proposal.
