[OpenAjaxInterop] Minutes 2008-12-08

[Javier H Pedemonte]

> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/interop/attachments/20081209/aacfe532/attachment.html