Interoperability Minutes 2009-01-12
From MemberWiki
URL: /member/wiki/Interoperability_Minutes_2009-01-12
Attendess
- Jon Ferraiolo, IBM
- Matthias Hertel
- Javier Pedemonte, IBM
- Kin Blas, Adobe
- Howard Weingram, TIBCO
- Ted Thibodeau, OpenLink
- Eduardo Abe, ILOG/IBM
Original agenda
- Agenda
- Rechartering about to become official
- Review recent spec editorial updates
- Introduction chapter
- New feature overview in Introduction
- PROPOSAL: Move library usage overview sections from Introduction chapter into Library Management chapter
- TODO: Still need to do various updates and cleanups to Introduction chapter
- Publish/Subscribe Overview chapter
- /member/wiki/OpenAjax_Hub_1.1_Specification_Publish_Subscribe_Overview
- Attempt to be a mashup primer, distinguish between Unmanaged Hub and Managed Hub
- Unmanaged Hub chapter
- /member/wiki/OpenAjax_Hub_1.1_Specification_Unmanaged_Hub
- No recent changes. Probably need to add an intro
- Managed Hub Overview chapter
- /member/wiki/OpenAjax_Hub_1.1_Specification_Managed_Hub_Overview
- Major update to some of the text
- Newly updated diagrams
- Newly added Definitions (and pictures) for terms ManagedHub instance, Container, IFrame Container, Inline Container, HubClient, and Widget
- Updated sample source code (still needs work, however)
- Moved Howard's architecture diagrams to bottom of this chapter
- PROPOSAL: Remove Howard's architecture diagrams
- Managed Hub Containers chapter
- So far, only renamed chapter title from "Providers" to "Containers"
- PROPOSALS
- Remove this chapter
- Add IFrameContainer and InlineContainer constructors to Managed Hub APIs chapter
- Add a short section on custom containers somewhere in the spec (probably Managed Hub Overview)
- Introduction chapter
Minutes
Rechartering
(Jon tells people that Interop WG rechartering looks like it will approved by end of day)
Hub 1.1 spec - Introduction chapter
Jon: I added a small section at the top to summarize the features in the Hub. Rest of the chapter is unchanged. This chapter needs a full editorial pass to make sure everything is up to date.
Jon: I propose moving some of the sections having to do with Ajax libraries to the Libraries chapter.
Howard: Fine.
Hub 1.1 spec - Pub/Sub Overview chapter
Jon: I attempted to make this chapter into a primer, where the primer explains what's different between an unmanaged hub and a managed hub. There is a comparison table at the bottom.
Howard: I like the table.
Hub 1.1 spec - Unmanaged Hub chapter
Jon: Need to add a couple of introductory sentences at top.
Howard: Maybe move the wildcards write-up into a generic chapter
Jon: Yes, that's right.
Hub 1.1 spec - Provider/Container chapter
Jon: I propose to move the provider/container APIs into the API chapter. One of the first things a mashup assembly application developer needs to do is to call constructor on a widget container. Best if there is one chapter with all of the APIs. This might mean elimination of the providers/container chapter.
Howard: I agree.
Jon: I propose a small section on container extensibibility
Howard: Yes, maybe a separate section on developing containers.
Matthias: Sounds good.
Jon: In API chapter?
Howard: Possible, but if you don't need something to use the API, then don't put it there. Don't make the APIs appear any more complicated than they are. The mind will do a calculation of complexity based on chapter length.
Matthias: yes
Jon: Complex enough without making it look more complex. OK, put into a separate chapter.
Hub 1.1 spec - Managed Hub Overview chapter
Howard: First 3 sections: maybe want to change. Maybe too intimidating. Need to see if possible to take things in steps.
Jon: Good feedback. Just a reminder that the goal this week was to produce an outline. I have material in the sections of the outline mainly due to shifting around things that were in the spec before.
Howard: Yes, understood.
Howard: Pictures needs to answer a particular question.
Matthias: Mashups are just one use case. But need a clear way of describing the features.
Howard: I very much agree. Lots of terminology not always needed.
Matthias: Good to write a chapter about what you might do.
Howard: Maybe have sutff like this in a section at back. really good ideas. Shows what we are thinking.
Jon: OK, will be some work. A mashup scenario usage chapter.
Howard: Yes, focuses on mashup scenarios. Maybe after if it can flow. Want to get to the meat of the spec faster.
New pictures
Matthias: (referring to one of the pictures, preferred old picture)
Howard: I like having 2 pictures instead of 1. I like the new ones better.
Jon: Old picture referred to "provider" rather than "container". With the new picture, I attempted to show containment.
Matthias: The container appears to encapsulate
Howard: This is a logical view. Maybe you can propose a different picture?
Matthias: Yes, I will try to do that
Howard: How about color blindness? Do a black&white view to see if colors blend together
Jon: Colors aren't essential to understanding the picture, but I'll print on b&w printer to see how it looks.
Howard: I like the pictures
Jon: Javier, you are in the code, what do you think?
Javier: I kind of agree. Need more time to digest the pictures and the text around it.
Howard: Some of the text is wrong. For example, it uses the word "broadcast"
Jon: I need to do more work on the sample code. Almost there, but not completely.
Hub 1.1 spec - API chapter
Jon: I removed the old overview. It was redundant mostly. Those parts that weren't elsewhere in the spec were added to other sections.
Jon: I propose we remove the architecture diagrams.
Howard: OK if there are other parts of the spec that make clear who implements wat
Jon: Let's review the rest of the spec before removing
Howard: Maybe the first picture doesn't have arrows. We need a simple picture up front, but maybe not this particular picture. Shows the static nature of the system.
Jon: What about the interactions picture?
Howard: This shows API interactions. Each picture should show a small number of things. Better to have more pictures that each show less.
Jon: I haven't had a chance to review "Other notes" yet
Matthias email
(reviewing email that Matthias sent just before meeting about the detailed APIs)
onComplete
Howard: Good question. I've been thinking we had an error code. NULL if no error or string if error
Jon: String or object?
Howard: Maybe an Error object?
Javier: I don't like null for success. Instead, always return an object with a boolean and an optional string. Also pass in subscription handle for some APIs.
Howard: I agree with subscription handle issue. Or clientId in some cases.
Matthias: Also need to document use case
Howard: Most important use case is HubClient. Need to know when subscribe has succeeded in the async case. For iframe, async. For inline, will be sync, and the onComplete will be called before the subscribe call returns.
Jon: Who will make a proposal?
Howard: I will, based on Javier's suggestion.
subscribe parameter reordering
Matthias: I suggest reordering the 1st 3 parameters so that they are the same as the Unmanaged Hub. Most people will only use the first 3.
Howard: I'm OK with that.
Javier/Jon: Yes
publish
Matthias: Need to document what "*" means
Howard: Yes, needs to be JSON compatible. Needs to be documented.
safeDelete
Matthias: I don't understand
Howard: Needed for when up in tree and sawing off a branch.
Matthias: No such problem. Gets deleted if no one references it. Garbage collection.
Matthias: Either document safeDelete or get rid of it.
Howard: I have to look back at it.
(This is a new open issue)
subscribeToClient
Matthias: subId parame - where does it come from?
Howard: Just a string. Unique within container.
Javier: Each container can define whatever it wants
(discussion)
Howard: Make implementation more efficient
Matthias: Designing APIs around implementation isn't usually good
Howard: Have to have subId anyway. This prevents an extra table and lookup.
Matthias: Could be a time stamp
Howard: Managed Hub doesn't care. Want to keep it so that we don't have to do a lookup.
Jon: Matthias, go along with Howard, are keep as open issue?
Matthias: Let's implement first
Howard: I have done one in Hub 1.0
Javier: I agree with what Howard is saying. Have it working in Hub 1.1 now. Only used by container.
Matthias: Topic alone isn't unique?
Javier: No, widget can subscribe to same topic multiple times. Look at the code and see what you think.
Matthias: Not an issue. If you can document it clearly, then OK.
Javier: Only an issue for people writing a new container. Mashup app won't use it.
connectToParent
(needs to be changed to "connect")
Jon: Just an error. Need to update spec.