Interoperability Minutes 2009-01-05

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-01-05

Contents

Attendess

  • Jon Ferraiolo, IBM
  • Matthias Hertel
  • Javier Pedemonte, IBM
  • Rama Gurram, SAP
  • Kin Blas, Adobe
  • Howard Weingram, TIBCO
  • Adam Peller, IBM

Original agenda

Minutes

Rechartering

(Jon reminds people that Interop WG rechartering voting ends on Jan. 6)

Spec and open source updates

Jon: I have completed the action from last phone call and have moved all of the approved proposals into the Hub 1.1 spec. Javier, how are things going with the open source update from your branch into mainline.

Javier: I succeeded with the merge.

Jon: You had told me you were having troubles.

Javier: I overcame them. It's all done.

Jon: Anything we need to change in the open source project?

Javier: Nothing urgent. If there is another big merge coming, it would be easier if the project upgraded, which requires download and upload of the entire open source project.

Howard: Let's leave things as they are for now. Maybe once the code is frozen, and let's do a practice run first.

Hub 1.1 spec updates

Jon: I moved the approved proposals into the spec. I simply copied the JSDoc comments into an HTML PRE element and inserted some wiki markup so that the page is in sections.

Howard: This approach makes it easy to keep things in sync

Jon: Yes, but we have to monitor each small change in the open source and then re-copy individual sections. I was thinking of a different approach where we take the original source code with JSDoc comments, run it through the JSDoc-to-OpenAjax Metadata converter, and then then that through XSLT to create wiki markup. That way, just run the automatic process and then copy/paste the result onto the web page. Just one big copy/paste and not many small ones. Also, kills two birds with one stone because this effort will help the IDE WG where we use Hub 1.1 as the sample Ajax library to showcase best practices.

Howard: Sure. But that's more longer-term. OK to leave things the way they are for now.

Jon: Yes, no hurry, so what I propose is that I get these converters working and then I'll create a second temporary wiki page so people can see what the results look like. Then we can decide whether to use the result, fix things or not use it.

Howard: Yes

Howard: Maybe move the overview section at the top of the API chapter to a separate wiki page.

Jon: There is a Managed Hub Overview chapter. Maybe it goes there.

Howard: OK. Maybe move the architecture diagrams there, too.

Jon: That's what I was thinking.

Howard: Maybe work on an outline first

Jon: Question about the provider chapter we have now. We need to change it from "provider" to "container". Right?

Many: Yes.

Jon: So, I propose that I take a crack in the next week at fixes to the 3 chapters, overview, APIs, and providers, and then we can review the chapters next week.

Howard: I agree.

Howard: Any references to client-server communications should be dropped. Instead, this might be something that happens inside of a container.

Jon: Yes. I already removed one reference to client-server comms, and I need to remove the others.

smash provider becomes iframe container

Howard/Rama/Javier: +1

Howard: Perhaps call it FIM container?

Jon: The iframe container uses both FIM and postMessage for cross-widget communications

Rama: Yes

HubClient vs ClientHub

Jon: Why is it ManagedHub and HubClient instead of ManagedHub and ClientHub?

Howard: HubClient isn't a Hub in itself. Emphasizes it's a client of the Hub and not a Hub in its own right.

Javier: That's the assumptions I had. I would say keep HubClient.

Jon: OK with me.

Matthias: I called it an extender. If you have terms that are have more difference, then it helps to distinguish.

Howard: I think "client" is good and "hub" is short.

Jon: I agree with Matthias's goals. If you didn't worry about length, then something like ClientContainer. Why not just "client"?

Howard: I worry that we might have multiple client types.

Jon: Any one object seriously to what we have now?

Matthias: I prefer extensions

Howard: Does it implement the Hub interface?

Matthias: Maybe have pictures of what we have?

Howard: We do have architecture diagrams at the bottom of the page.

Jon: I'll update the pictures and the text, and then we can look at it and decide what name changes we think we need

Should ManagedHub be a class or interface

Howard: Should be a class

Was there a typo in OpenAjax.hub.Hub.prototype.disconnect

Howard: Yes, that's a typo

Howard: Note that it has a different API and different behavior on ManagedHub vs ClientHub. If people want to mangle together these two things, that's OK, but I prefer to keep them separate

Javier: Yes

getParameters

Javier: Howard had a good email, but I forgot to respond. Howard's 3rd option is the best.

Jon: I forgot about that, so I'm not prepared on Howard's proposals.

Howard: Let's come back to the issue next week.

Jon: OK. Current proposal is option #3. Let's discuss in email and then close next week.

Opaque subscription handle

Jon: There is a question at the end of the API wiki page about whether subscription handle is opaque or not.

Howard: I'll have to get back to you on that. I forgot the discussion.

Javier: We decided on opaque, container-specific

Howard: OK, let's assume that. Need to be able to get information out of an object one way or another

Javier: I'm leaning towards methods on the container, pass in a subscription handle

Howard: I'm leaning the other way, methods on subscription object. So leave as an open issue.

OpenAjax.hub.utilities

Howard: Was for safeDelete/etc. Don't need that any more.

Namespacing topics

Jon: Open issue from long ago. I don't think we need to do anything more here. We have Hub 1.0 best practices, which talk about reverse domain syntax. And we have talked about a public Registry for people to define topics.

Howard: I agree. Regarding the registry, we want to make this a public thing and get us out of managing the registry.

Javier: We also talked about a set of common topics. Helps with typing.

Howard: This is separate and orthogonal from Hub standardization. Still worth doing.

Jon: This task is still in our open task list.

Howard: What I mean, the common topics defined by OpenAjax would be no more important than other topics defined by the community, except that they are defined by OpenAjax.

Limited history, last event

Howard: Punt for now.

Jon: Yes, that's what we decided at F2F. Any objections?

(none)

Payload datatype

Jon: I recommend that we punt for now. JSON Schema would be appropriate down the road, but we need to finish what we have.

Howard: Sometimes JSON, sometimes plain text. Don't want to bog down the core standard with that kind of limitations. Can add something in the future.

Jon: Yes, need to finish what we have.

Howard/Jon: Good thing to do, but not now.

Jon: (Thinking to the future) Could add a schema attribute to OpenAjax Metadata's <topic> element

Howard: Need to make sure that multiple schema can be specified.

Retrieved from "http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-01-05"
Personal tools