[OpenAjaxInterop] Minutes 2008-12-08

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

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.


             Howard Weingram                                               
             <weingram at tibco.c                                             
             om>                                                        To 
             Sent by:                  Javier H                            
             interop-bounces at o         Pedemonte/Austin/IBM at IBMUS,         
             penajax.org               <interop at openajax.org>              
             12/09/2008 09:56                                      Subject 
             PM                        Re: [OpenAjaxInterop] Minutes       

(e) in more detail, the functionality at the hub level is as

    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

    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?


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
>> 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
>> 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
>> unpleasant consequences.
> My vote would be for (e).  I think returning an error where the client
> know if all subscribers failed to get the publish event or just some of
> will just lead to confusion.  Plus, doing (a) or (b) would complicate the
> code.
> I still tend to think of clients as almost standalone, in that they don't
> who has subscribed to them.  Therefore, the publish event can just "fail"
> silently (although I wouldn't really characterize it as a failure).  If
> needs to be any logic about which client publishes to another, then that
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/interop/attachments/20081210/ddbd7ba5/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/ddbd7ba5/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic21773.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/ddbd7ba5/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/ddbd7ba5/attachment-0002.gif 

More information about the interop mailing list