From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-02-09

Attendess

Jon Ferraiolo, IBM
Matthias Hertel
Javier Pedemonte, IBM
Kin Blas, Adobe
Howard Weingram, TIBCO
Eduardo Abe, ILOG/IBM

Minutes

Common callbacks

RESOLUTION: Move onComplete into common area, move onData into Hub area

subscriberData as "*"

(Jon was making sure that was OK)

RESOLUTION: Yes, that's OK

Remove all equals() methods

Javier/Howard/Jon: Yes

Javier: Was left over from older APIs

Jon: You can put === in your own code

RESOLUTION: Remove all equals() methods

ManagedHub constructor

RESOLUTION: Accept Howard's renaming of onSecurityAlertCallback to onSecurityAlert

Jon: Is the signature for onSecurityAlert OK? Should 'source' say 'item' to be consistent to onComplete?

Javier: Not really the same.

Jon: OK, leave it as source

Matthias: There was discussion about console logging in email

Howard: That was for onWarning

Jon: Does onSecurityAlert only apply to priveleged code?

Howard: Can go to application code, include client application

Matthias: Regarding logging, this would be great for developers

Jon: This would be an implementation feature, not a spec feature

Howard: Originally, I thought it would be difficult to debug with all sorts of frames and libraries, and that onWarning could be used for that. But security alert is a different situation. Can't use console logging. Needs to be handled. Makes sense to keep.

Matthias: Yes

Matthias: onWarning is misleading if mainly for logging.

Howard: Such as when a container is notified of a version number message or after disconnect a message was thrown on the floor. Nothing to show end user or do anything with. So just rely on the console. Don't standardize. Implementation detail. However, security alert is part of the strict contract.

Howard: Is everyone OK with: (1) Keep onSecurityAlert as is, (2) get rid of onWarning in all cases, (3) Where we have onWarning in the reference implementation, we use console logging

Javier/Matthias: Yes

RESOLUTION: Accept Howard's 3 points

Description of onSecurityAlert

Javier: How about saying in the text that any message that is listed as REQUIRED will throw a BADPARAMETERS if not provided?

Howard: Yes

Howard: Make a note in JSDoc that we need to list exceptions

Jon: I'll do that

onSubscribe and onPublish callbacks

RESOLUTION: Fine as is

RESOLUTION: Good to change 'clientId' to "container'

Do we need other getters?

Javier: Can't see how they would be needed

Howard: I say leave them out

Javier: Security Alert handler might have a use

Howard: Keep getSecurityAlertHandler but get rid of the rest

RESOLUTION: Keep getSecurityAlertHandler but get rid of the rest

Container constructor

Jon: Most of the red-colored comments are obsolete

Jon: Could people look at the definition for clientId

Javier: It's a string. Don't need the word opaque

Jon: OK

Jon: Is Container an interface or class?

Javier/Howard: A base class

(Howard's question about whether we should say that the classes are "protected" or "public")

Javier: Just say they are accessible by the derived classes

Howard: Or we could add more getters

Javier: Yes, for symmetry

Howard: Only one that isn't easy are subscriptions, which is an implementation detail. I'll toss around some ideas.

Jon: In email, please

Container onConnect callback

(Jon asked for an explanation of who uses this)

Howard: When making a container, these are the callbacks for when a client connects and disconnects. Optional, but often disconnect is important

Jon: OK, makes sense

Jon: Any objections?

RESOLUTION: Approve onConnect and onDisconnect callbacks

IframeContainer new parameters: uri, tunnelURI, parent

Jon: Anyone disagree with the three new parameters?

Matthias: These are implementation-specific, except uri. Maybe you don't need tunnel.html. In a couple of years, all browsers will use postMessage.

(discussion about how tunnelURI is required if you use FIM technique, and how we want to standarize that API so there is interoperability for implementations that use FIM)

Jon: How about we include tunnelURI and say "Required for FIM containers (see notes below)"

Howard: Sure

Matthias: How about using factory method approach? Just a thought.

Howard: This chapter is for application developers. The container chapter is for container developers. Factory approach would just move the bubble around. Still need to identify your container.

Matthias: OK

Howard: Let's leave it as is, but say our reference implementation requires it. I'll try to write it up in email.

Matthias: OK

RESOLUTION: Accept the 3 new parameters.

HubClient constructor

Jon: Looks fine now

InlineHubClient constructor

Jon: Looks like you didn't update the wiki page

Howard: Yes, I will now.

Javier: How do you get access to the container object?

Howard: This is on the manager side.

Javier: In the reference implementation, we try to keep code as simple as possible. I'll think about this one. Fine for now.

RESOLUTION: Accept Howard's proposals.

Containers chapter

Jon: Can we delete all of the ancient text about providers at the bottom?

RESOLUTION: OK to delete ancient text about providers

Definitions within Introduction chapter

Howard: I added a Frame Phishing definition

Howard: Ok to have mention of security techniques scattered about, but do we want to have spec include rigorous discussion of security techniques? Here are the options: (1) Incorporate security discussions within main body of spec. But this would become overwhelming. (2) Add an appendix. (3) Separate white paper. (4) Do nothing.

Jon: Best approach is a separate wiki page. We might need to update the security write-up more often than the main spec.

Howard: I agree. Except keep small things like definition of phishing.

Best practices

Howard: I made some additions

Jon: Generally, all really good. Maybe some details to discuss. Next week.

Interoperability Minutes 2009-02-09