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

[Javier H Pedemonte]

Howard Weingram <weingram at tibco.com> wrote on 12/04/2008 05:35:15 PM:

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

Sounds fine to me.  Let's keep it in.

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

OK, this sounds fine, but we'll definitely have to explain this somewhere, 
maybe in a "tips" or "best practices" page.

> 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

Then we should add something like "NotAllowed" to OpenAjax.hub.Error.

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

Sounds good.

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

Yes, I am all for having a single onError function that handles errors and 
security alerts.  And I like sending an error if publish fails, but not 
sure if we should do so if publish is denied.  The way I see it, the 
clients are blind as to what the manager is doing.  If the manager chooses 
to disallow a pub/sub, is there any reason to tell the client?


Javier H Pedemonte


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/interop/attachments/20081205/60ce07b0/attachment.html