[OpenAjaxInterop] Minutes 2008-12-08

Howard Weingram weingram at tibco.com
Tue Dec 9 21:56:31 PST 2008


(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



More information about the interop mailing list