Interoperability Minutes 2009-01-12

From MemberWiki

Jump to: navigation, search

URL: /member/wiki/Interoperability_Minutes_2009-01-12

Contents

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
      • Publish/Subscribe Overview chapter
      • Unmanaged Hub chapter
      • 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)

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.

Personal tools