[OpenAjaxInterop] Howard's changes to Hub 1.1 proposal page
Javier H Pedemonte
pedemont at us.ibm.com
Mon Dec 8 13:26:45 PST 2008
Howard Weingram <weingram at tibco.com> wrote on 12/05/2008 03:52:35 PM:
> >> 3. getParameters()
During the call today, Jon brought up the point that the getParameters()
function is on the Hub interface, which means it is a method on both the
ManagedHub and HubClient impls (it is also a function on the Container
base object). But you only described it being used as a function on
ManagedHub. Should we only have this function on ManagedHub?
> 5a. Regarding one or two onError functions:
>
> Currently, I have been using 2 different functions:
>
> * onSecurityAlertError
> * onWarning
>
> The onWarning function handles asynchronous errors that do not appear to
be
> dangerous, while the onSecurityAlertError reports suspected attacks. My
> thinking is that we need an easy way to distinguish suspected attacks
from
> less urgent issues. I avoided forcing the triage mechanism to depend on
> exhaustive enumeration of specific errors, because different
> Container/HubClient implementations may have specialized
errors/warnings.
> Generic application code may not recognize every type of error/warning
> generated by every type of Container. Treating every warning as a
suspected
> attack would probably be overkill. Treating a suspected attack as a
warning
> could be a big mistake. I could have had some kind of severity flag, I
> suppose, but I figured that a manager's behavior when an attack is
suspected
> (we probably destroy the container immediately) is much more extreme
than
> the behavior when a "warning" is received. Thus, I separated the two
> handlers. Since many applications might not care about warnings at all,
2
> functions seemed easiest and most efficient. However, a severity flag is
> another possible option.
This seems fine to me. And I prefer the 2 functions rather than a
security flag.
> 5b. Tangent: viewing permission-denied as warning vs. as attack
>
> Right now I am treating authorization failures (onPublish returns false)
as
> warnings rather than as attempted attacks. I don't know whether everyone
> else agrees with this approach.
>
> 5c. Regarding why we should tell the client when publish fails (good
> question):
I'm fine with both of these.
Javier H Pedemonte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/interop/attachments/20081208/3f56006c/attachment.html
More information about the interop
mailing list