[OpenAjaxInterop] Minutes 2008-12-08

Jon Ferraiolo jferrai at us.ibm.com
Wed Dec 10 17:04:23 PST 2008

Hi Howard,
Regarding "You meant onComplete...", I have updated the minutes and one of
the wiki pages with corrections.

Regarding "OpenAjax.hub.Hub" and following Java capitalization conventions,
and the benefits of having a SHORT name, that's good enough of an
explanation for me. :-)


             Howard Weingram                                               
             <weingram at tibco.c                                             
             om>                                                        To 
                                       Jon Ferraiolo/Menlo Park/IBM at IBMUS, 
             12/09/2008 12:42          <interop at openajax.org>              
             AM                                                         cc 
                                       Re: [OpenAjaxInterop] Minutes       

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

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

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
> 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
> 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
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
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
> 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
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
> 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
> next week.
> Jon: Change the Hub 1.1 spec now? I'm interested in updating the Hub 1.1
> ASAP to reflect our most current thinking. What's there now is out of
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/interop/attachments/20081210/b5ab125e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/b5ab125e/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic16433.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/b5ab125e/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/b5ab125e/attachment-0002.gif 

More information about the interop mailing list