[OpenAjaxInterop] Howard's changes to Hub 1.1 proposal page

Jon Ferraiolo jferrai at us.ibm.com
Wed Dec 10 16:57:04 PST 2008

OK, thanks. Yes, it makes sense to leave getParameters() on


             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/08/2008 11:10                                      Subject 
             PM                        Re: [OpenAjaxInterop] Howard's      
                                       changes to Hub 1.1 proposal page    

See below.

On 12/8/08 1:26 PM, "Javier H Pedemonte" <pedemont at us.ibm.com> wrote:

> 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
> object).  But you only described it being used as a function on
> Should we only have this function on ManagedHub?

HubClient constructors must also take a params object, and
HubClient.getParams() allows client code to retrieve this in a standard
manner, as with ManagedHub.getParams().

So I have a slight preference for leaving this function on the common Hub

>> 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
>> dangerous, while the onSecurityAlertError reports suspected attacks. My
>> thinking is that we need an easy way to distinguish suspected attacks
>> 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
>> Generic application code may not recognize every type of error/warning
>> generated by every type of Container. Treating every warning as a
>> attack would probably be overkill. Treating a suspected attack as a
>> 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
>> (we probably destroy the container immediately) is much more extreme
>> the behavior when a "warning" is received. Thus, I separated the two
>> handlers. Since many applications might not care about warnings at all,
>> 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
> flag.


>> 5b. Tangent: viewing permission-denied as warning vs. as attack
>> Right now I am treating authorization failures (onPublish returns false)
>> 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
> _______________________________________________
> 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/3b849f30/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/3b849f30/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic05224.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/interop/attachments/20081210/3b849f30/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/3b849f30/attachment-0002.gif 

More information about the interop mailing list