[OpenAjaxInterop] Howard's changes to Hub 1.1 proposal page

Howard Weingram weingram at tibco.com
Thu Dec 4 15:35:15 PST 2008


Hi Javier. My comments:

1. subscriberData

    There are several subscribe() functions.
    OpenAjax.hub.subscribe(): currently takes subscriberData, and I think
        that we agreed to continue this.
    OpenAjax.hub.Hub.subscribe() in OpenAjax.hub.Hub interface:
        It turns out that this is kind of useful. It allows
        "static" functions to receive subscription data.

    I guess I can take it out, but I am very tempted to leave it in.
    Otherwise programmers tend to be forced to create lots of callback
    functions, even when the app does not need this.

2. unsubscribe()

    OpenAjax.hub.Hub.unsubscribe(subHandle, onDone) should take an
    onDone callback. I agree.
    
3. getParameters()

    I added this to ManagedHub because I have information on the
    ManagedHub that containers are very likely to use.

        a. Containers should be able to use their Managedhub's
            onSecurityAlert callback to notify the Manager of
            security violations. There is no standard API to
            get this function, and rather than add a separate
            function to the MH API (getOnSecurityAlert) I
            think that being able to get the hub params and
            extract the onSecurityAlert callback via its well-
            known param name is a good thing. Note that Container
            is not allowed to access ManagedHub private interfaces,
            so in order to call MH's security alert callback, there
            must be a public way to get this callback.

        b. I have added a "scope" parameter to the params in the
            MH constructor. Containers should be able to use
            their ManagedHub's scope parameter for onConnect,
            onDisconnect, and the manager's onSecurityAlert
            callbacks. As above, there is no MH.getScope(), just
            getParams(), which returns the params object, from
            which you can get scope via "params.scope".

    Alternatively, I could instead have forced code that creates
    every Container to redundantly pass around this same information,
    but it will be easier if this is done only once, when
    the ManagedHub is created.

    HubClient and Container implementations will also take params.
    I included getParams() in these cases largely for consistency.

4. sendEvent() takes subId

    I agree 100%. The lack of subId was a typo in the version of the
    interface that I pasted into the wiki page. I thought I had fixed
    this before. I have now fixed it. Thank you for catching it!

5. subscribe() disallowed in onSubscribe()

    First a tangent: there are several scenarios on the subscribe side.

    a. ManagedHub.subscribe() successful

        Returns SubscriptionHandle
    
    b. ManagedHub.subscribe() fails due to bad topic or ManagedHub is
        being cleaned up and permits no more subscribe operations.

        Throws an appropriate exception

    c. HubClient.subscribe() successful

        Returns SubscriptionHandle

    d. INLINE HubClient.subscribe() causes Manager to call onSubscribe,
        which returns false, causing request to be denied.

        Before subscribe returns, onDone is synchronously invoked
        to report the error. Then subscribe() automatically destroys
        the dead SubscriptionHandle and returns null.

    e. FIM/POSTMSG HubClient.subscribe() causes Manager to call
        onSubscribe, which returns false, causing request to be denied.

        Subscribe returns a SubscriptionHandle, because we cannot
        tell yet whether the operation succeeded or failed.
        Some time after subscribe returns, the subscription's
        onDone is invoked to report the error, after which the
        SubscriptionHandle is automatically destroyed.

5a. Now the comment about Publish:

    I did not include this in my first revision, but in one
    implementation I have an optional parameter that can be included
    in the params for any ManagedHub or HubClient contructor. This
    parameter is a callback for handling asynchronous warnings.

    params = {
        onPublish: ...,
        onSubscribe: ...,
        onSecurityAlert: ...,
        onScope: ...,
        onWarning: ...
    }

    This callback is used when something that is not a serious
    security error occurs asynchronously.

    Or, we could simply turn onSecurityAlert into onError, and
    have it called in these cases too; the code would then need
    to check the error code to see if the problem were serious.

What do you think?

Howard

On 12/4/08 2:04 PM, "Javier H Pedemonte" <pedemont at us.ibm.com> wrote:

> Some thoughts on the latest changes:
> 
> * I thought we decided to get rid of 'subscriberData' for subscribe()?  Do you
> now think it would be good to keep this around?
> * For OpenAjax.hub.Hub.prototype.unsubscribe(), does the user just assume that
> the operation succeeded (like publish()), or should we have an onComplete()
> callback?  I'm not sure if a callback would get us much here, but just wanted
> to bring this up, as the old APIs had such a callback.
> * What is the point of the 2 getParameters() functions?  I can't think of a
> good use case where these would be useful.
> * In the code I just checked in, I have the sendEvent() function taking a 3rd
> parameter: the subscription id.  My reasoning is that if the function only
> takes 'topic' and 'data', then the container must have its own mini
> subscription tree (or at least an associative array).  But it must also keep a
> mapping between the subscription handle and relevant data.  But if sendEvent()
> takes 'topic', 'data' and the subscription ID, it makes things easier.
> * If a subscribe() is disallowed by the onSubscribe callback, then
> subscribeForClient() should return false; true otherwise.  The same cannot be
> done for the onPublish callback, since the publish events don't give feedback.
> 
> I also have some minor edits to the API wiki (still to be done), mainly to the
> descriptions.  Also, JSDoc question: how do you represent a type that can be
> anything?  I've been using "*", but I'm not sure that's right...
> 
> 
> Javier H Pedemonte
> 
> 
> _______________________________________________
> interop mailing list
> interop at openajax.org
> http://openajax.org/mailman/listinfo/interop



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