[OpenAjaxInterop] Minutes 2008-12-08

[Jon Ferraiolo]

Interoperability Minutes 2008-12-08



URL:
http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-12-08




Attendees
      Matthias Hertel
      Jon Ferraiolo, IBM
      Ted Thibodeau, OpenLink
      Rama Gurram, SAP
      Javier Pedemonte, IBM
      Kin Blas, Adobe

Minutes


Agenda is to review emails in past 10 days, particularly:
      Javier: http://openajax.org/pipermail/interop/2008q4/000694.html
      Howard: http://openajax.org/pipermail/interop/2008q4/000696.html
      Javier: http://openajax.org/pipermail/interop/2008q4/000699.html
      Howard: http://openajax.org/pipermail/interop/2008q4/000700.html
      Javier: http://openajax.org/pipermail/interop/2008q4/000695.html

subscriberData


Jon: Howard, Javier and I lean towards adding it back in.


Javier: Howard gave some good reasons to keep it.


Jon: Any objections to putting it back in?


Matthias: We can keep it.


RESOLUTION: Include subscriberData



unsubscribe onDone


Jon: Decided we needed an onDone callback


Javier: Yes, an async callback is useful in some situations. Howard said it
was a mistake to not have it.


Jon: Any other comments?


RESOLUTION: Include subscriberData



getParameters


Jon: I wasn't sure about this one. Need to talk to Howard. Is this just a
manager-side feature or is there use on the client also?


Javier: I wasn't sure either. I'll check emails. Maybe can be moved up from
base to Managed Hub.


(will keep this open until we can talk to Howard)



sendEvent subscriptionId


Jon: Lack of subscriptionId an oversight?


Javier: Yes, correct.


RESOLUTION: Add subscriptionId



subscribe/publish callbacks


Jon: This is the most involved item, with multiple parts. First, Howard
provided a breakdown between Managed Hub and Client Hub, between inline
container and iframe container, etc. Everyone agreed with his breakdown.


Jon: Next item was whether we needed a NotAllowed.


Javier: I agree with adding it.


Jon: Any other comments?


RESOLUTION: Add NotAllowed


Jon: Next item is multiple versus single callbacks


Javier: I'm indifferent. I'm OK with Howard's proposal.


Matthias: I prefer a single error routine.


Javier: Main thing was security callbacks vs other error callbacks. Howard
thought it was better to separate out the security concerns.


Matthias: You think a component might want to shut down if security
problems? That's a good point.


RESOLUTION: Accept Howard's proposal for separate security callback


Jon: On a tangent issue, should client even find out about being denied
permission? My feeling is yes. There is an argument that any information to
malicious components is bad, but in this case, either we are sandboxing or
we aren't. OK to tell components they were denied, but don't provide any
details.


Javier: I'm fine with that.


Matthias: I agree. We have a rule that we when we have no connection, we
always have to provide the same error.



JSDoc "*"


Jon: Yes, that's the right thing to do. I'll make sure our JSDoc to OAM
converter does the right thing with "*".



Property naming conventions


Jon: Howard proposes camel case for public names and an initial underscore
for implementation-specific private things. That matches our precedent from
Hub 1.0. Therefore, I like his proposal.


Javier: Fine with me.


(no objections)


RESOLUTION: Accept Howard's proposal for property naming conventions



onPublish, onSubscribe as required


Jon: Howard wants to force manager developers to have to take at least a
bit of action towards security by forcing them to provide these two
callbacks, even if they just return true. I agree with his reasoning.


Javier: Yes, but I'm always skeptical about things that require dummy
functions. But his reasoning is fine with me.


RESOLUTION: Accept Howard's proposal for requiring onPublish, onSubscribe



OpenAjax.js inside of OpenAjax-mashup.js


Jon: It looks like Howard has included logic and APIs for Hub 1.0 within
OpenAjax-mashup.js.


Javier: I haven't looked at the most recent check-ins.


Jon: I'm OK with that as a short-term developer expediency, but before we
go final, we need to find a way to have a small footprint version that
people can use when they only need Hub 1.0 functionality. Maybe separate
back out the OpenAjax.js file or duplicate the logic where a developer can
either use OpenAjax.js or OpenAjax-mashup.js.


Javier: Agreed


Matthias: Yes, what you said is right


RESOLUTION: We need to find a way to allow developers to use Hub 1.0
functionality with small footprint and not force everyone to include
OpenAjax-mashup.js



OpenAjax.hub.Hub


Jon: This is confusing. Why hub.hub? Why is one lowercase and the other
uppercase? Can we find a different name for the 3rd part?


Javier: I believe no one implements OpenAjax.hub.Hub. It's just interfaces
that are implemented by ManagedHub and ClientHub. We could call it
HubInterface or HubIFace.


Jon: Therefore, if not implemented anywhere, OK to use a longer name, such
as HubInterface.


Jon: Not a critical issue at all. Whatever we decide isn't that important
one way or the other.



Moving Hub 1.1 branch to mainline, updating Hub 1.1 spec


Jon: Should we move the Hub 1.1 branch with the new APIs to mainline?


Javier: Not yet. Still need to work on smash provider. Let's talk about it
next week.


Jon: Change the Hub 1.1 spec now? I'm interested in updating the Hub 1.1
spec ASAP to reflect our most current thinking. What's there now is out of
date.


Javier: Best to wait one more week.


Jon: OK.



Next phone call


Jon: Let's have a phone call next week to go over any remaining issues and
review what we learn from implementing. Might be a short phone call, but
let's have one nonetheless.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/interop/attachments/20081208/0d0b0d37/attachment.html