[OpenAjaxInterop] Minutes 2008-12-08

Howard Weingram weingram at tibco.com
Wed Dec 10 18:34:36 PST 2008


Thanks, Jon. 

If clients *require* the ability to communicate with specific other clients,
such that the application will break if such communication is denied, then
it is up to "the application" rather than the hub to perform whatever checks
are needed to ensure that this ability exists and, if it does not exist, to
degrade gracefully or shut down cleanly. This is a BEST PRACTICE that we can
include in the Best Practices document for application developers.

>From the perspective of the hub, any Gadgets framework that sits on top of
the hub is considered to be "part of the application."

I am willing to let this point rest. (e) it is, unless someone objects.

hw


On 12/10/08 5:15 PM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:

> I agree with Howard and Javier that we should go with (e), and I agree with
> Howard's detailed explanations.
> 
> One more comment. If there are scenarios where a widget needs to know whether
> it has the about the ability to communicate with other widgets, we are getting
> into a higher level of functionality, something more akin to the "feature"
> feature that Howard proposed in the Gadgets TF, where one component requires
> that there is another component that implements a particular set of APIs. This
> is likely to be a slippery slope that would get us into a general COM-like
> remote procedure call capability, which we discussed at the F2F and decided to
> postpone to a future release.
> 
> Jon
> 
> 
> Howard Weingram <weingram at tibco.com>
> 
> 
>>>>> Howard Weingram <weingram at tibco.com>
>>>>> Sent by: interop-bounces at openajax.org 12/09/2008 09:56 PM
> 
> To
> 
> Javier H Pedemonte/Austin/IBM at IBMUS, <interop at openajax.org>
> 
> cc
> 
> 
> Subject
> 
> Re: [OpenAjaxInterop] Minutes 2008-12-08
> 
> (e) in more detail, the functionality at the hub level is as
> follows: 
>  
>     When onSubscribe denies a client's permission to subscribe
>     to a topic, the Container communicates the rejection to the
>     HubClient. The HubClient notifies the client application
>     via the onComplete callback, specifying the error
>     (OpenAjax.hub.Error.NotAllowed) and identifying the
>     HubClient subscription handle associated with the
>     rejection.
> 
>     When onPublish prevents a data item published by a client
>     from being delivered to a subscriber, THE PUBLISHING
>     CONTAINER IS NEVER NOTIFIED. When a client publishes, it
>     cannot tell how many subscribers exist, and it cannot tell
>     how many of the existing subscribers received the published
>     data item.
> 
> I will go with (e).
> 
> Does anyone else want to comment?
> 
> hw
> 
> On 12/9/08 9:55 AM, "Javier H Pedemonte" <pedemont at us.ibm.com> wrote:
> 
>>>> 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
>>>     unsuccessful.
>>> 
>>>     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
>>>         NotAllowed.
>>>     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.
>> 
>> My vote would be for (e).  I think returning an error where the client
>> doesn't
>> know if all subscribers failed to get the publish event or just some of them
>> will just lead to confusion.  Plus, doing (a) or (b) would complicate the hub
>> code. 
>> 
>> I still tend to think of clients as almost standalone, in that they don't
>> know
>> who has subscribed to them.  Therefore, the publish event can just "fail"
>> silently (although I wouldn't really characterize it as a failure).  If there
>> needs to be any logic about which client publishes to another, then that
>> needs
>> to be handled at the manager level...
>> 
>> 
>> 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
> 
> _______________________________________________
> 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