[OpenAjaxInterop] Minutes 2008-12-08

Howard Weingram weingram at tibco.com
Tue Dec 9 00:42:26 PST 2008

Hello everyone.

I am including comments below.

The "wiki page" that I reference below is, for your convenience:


On 12/8/08 12:21 PM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:

> Interoperability Minutes 2008-12-08
> URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-12-08
> <http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-12-08>

> subscriberData 
> RESOLUTION: Include subscriberData

Committed in OpenAjax-mashup.js
Wiki page updated

> unsubscribe onDone
> RESOLUTION: Include subscriberData

You meant onComplete here, not subscriberData.

Note: I changed the parameter name from onDone to onComplete because when a
reader skims over documentation, onDone and onData look quite similar and
this may lead to unnecessary bugs due to transposition of these parameters.

Committed in OpenAjax-mashup.js
Wiki page updated

> 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)

I have responded to Javier's query, but this is still open for discussion.

> sendEvent subscriptionId
> RESOLUTION: Add subscriptionId

Committed in OpenAjax-mashup.js
Wiki page updated

> subscribe/publish callbacks
> Jon: Next item was whether we needed a NotAllowed.
> RESOLUTION: Add NotAllowed

API committed in OpenAjax-mashup.js for subscribe()
Wiki page updated for subscribe()

More comments about NotAllowed & publish() later.

> Jon: Next item is multiple versus single callbacks
> RESOLUTION: Accept Howard's proposal for separate security callback

API committed in OpenAjax-mashup.js
Wiki page updated

> 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.

On subscribe, this is easy and makes a lot of sense.

On publish, it turns out that this is a lot more problematic. There are 2
serious issues.

1. The onPublish callback does not actually prevent a publish. It
    prevents individual subscribers from receiving the published
    data. So a single publish() may be both successful and

    Possible resolution: NotAllowed indicates that perfectly
    legitimate subscribers (which were allowed to subscribe to
    topic T by onSubscribe) were prevented by onPublish from
    receiving a message published on topic T.

    If we adopt this approach, then publishForClient throws
    NotAllowed if onPublish returns false for even one of the
    subscriptions, and HubClient notifies the client code of
    the failure.

2. If the HubClient notifies the client application that a
    publish attempt was NotAllowed, then the client
    application probably needs to determine which publish
    failed. Is the information contained in the warning
    sufficient to identify the culprit?

    Some possible approaches:

    a. Hub.publish should return a handle or token that can
        be provided in the onWarning callback, to associate
        the callback with a specific publish.
    b. NAK returns topic and data that were published, and
        the onWarning callback includes topic and data in
        this case.
    c. Provide an onComplete callback for publish.
    d. Punt. Don't try to match callbacks to publishes. Client
        just gets a generic error saying that some publish was
    e. Eliminate all notification of NotAllowed for publish
    f. Eliminate all notification of NotAllowed for subscribe
        as well as for publish.
If we were to do (f), then the HubClient does not tell the client anything.
Any given publish or subscribe could fail silently. If a client needs to
know about failures, this must be implemented at a higher level (ugly,
probably redundant). Silent failures in infrastructure code can have very
unpleasant consequences.

> Property naming conventions
> RESOLUTION: Accept Howard's proposal for property naming conventions

Committed in OpenAjax-mashup.js

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

Committed in OpenAjax-mashup.js
Wiki page updated

> 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.


> 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.
> 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

I agree that we should also have a small-footprint version.

Let's look at which of these approaches works best once we are done tweaking
the interfaces. 

> 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?

For those familiar with Java packages, I used a package-like notation as an
organizational principle. OpenAjax.hub corresponds to the "package".
OpenAjax.hub.Hub is the "interface". Package names in Java are lowercased
(I'm excepting OpenAjax from this), whereas class and interface names are
typically upper-camel-cased and actual functions are lower-camel-cased.
Thus, "OpenAjax.hub.ManagedHub.subscribeForClient()".

This distinction allows us to group our classes, interfaces and functions in
an orderly way:

* OpenAjax.hub.ManagedHub ("class"),
* OpenAjax.hub.SubscriptionHandle ("class", well, just an opaque handle)
* OpenAjax.hub.HubClient (an "interface")
* OpenAjax.hub.Container ("interface")
* OpenAjax.hub.Hub ("interface")
* We still have OpenAjax.hub.subscribe, etc. but I'm happy to
    leave them exactly as they are.

Again, I am using this naming structure as an organizational principle. I
don't want to carry it "too far". JavaScript is not Java. However, this
seems to work pretty well.

> 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.

That's fine too. However, I like Hub because it's SHORT. Also, if we're
going to name anything "FooInterface" then we should name all of the
interfaces as interfaces (HubInterface, ContainerInterface and
HubClientInterface). I think what we have now is clearer.

OpenAjax.hub.Hub is simply an interface. It is "extended" by
OpenAjax.hub.ManagedHub and OpenAjax.hub.HubClient. I included
OpenAjax.hub.Hub in the proposed interface definition in order to force us
to maintain a degree of consistency between ManagedHub and HubClient. This
allows some application or toolkit code to be written without regard for
whether the toolkit code is supposed to run on the manager side or the
client side; something hands the toolkit a Hub instance, be it a HubClient
instance or a ManagedHub instance, and the toolkit uses that Hub instance to
pub and sub. 

Hub *never* gets instantiated. We can remove the actual Hub function from
the reference implementation. We may want to leave it in the documentation
in order to show that application code really should be able to treat a
ManagedHub like a HubClient in terms of certain functions.

> 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. 

I agree. 

Thanks for all of your work, feedback & input!

Best Regards,

Howard Weingram      650.846.1000
Principal Architect  TIBCO Software Inc.

TIBCO PageBus(TM) delivers ultra-lightweight
publish-subscribe messaging for mash-ups.
Learn more at http://www.pagebus.org

More information about the interop mailing list