[OpenAjaxGadgets] Remove <property topic="">

Howard Weingram weingram at tibco.com
Tue Apr 14 09:54:30 PDT 2009


Let's hold off on this one by a week, actually, and discuss it in next
week's meetings, when I will be able to attend.

Regards,
Howard 


On 4/14/09 9:09 AM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:

> 
> I'm fine with removing the 'topic' attribute from the PROPERTY element.
> 
> But why MAY instead of SHOULD? What are the reasons that the property
> management system wouldn't send notifications?
> * Are you thinking that some host software environments won't implement
> shared properties, and this is OK?
> * Are you thinking that some host software environments will implement
> shared properties, but will have security systems that will restrict which
> properties are shared?
> 
> I'm asking this because we might want to include informative text that
> provides some explanation about various scenarios where property values
> might be shared or might not be shared.
> 
> Jon
> 
> 
> 
> 
>                  
>              Howard Weingram
>              <weingram at tibco.c
>              om>                                                        To
>              Sent by:                  "gadgets at openajax.org"
>              gadgets-bounces at o         <gadgets at openajax.org>
>              penajax.org                                                cc
>                  
>                                                                    Subject
>              04/11/2009 06:03          [OpenAjaxGadgets] Remove <property
>              PM                        topic="">
>                  
>                  
>                  
>                  
>                  
>                  
> 
> 
> 
> 
> Hello, folks.
> 
> Having seriously thought about some of the comments last week, I would like
> to propose a simplification of the <property> pubsub behavior along the
> lines briefly suggested last week.
> 
> Allow <property> to have the following pubsub attributes, with the
> following
> specified meanings:
> 
> 1. Attribute: publish="<Boolean>"
> 
> If the publish attribute is present and true, then when the property
> management system sees a change in the value of this property, it MAY
> notify
> other widgets (not just this widget) of the change.
> 
> 2. Attribute: subscribe="<Boolean>"
> 
> If the subscribe attribute is present and true, then when the property
> management system detects a change in the value of this property, it MAY
> notify this widget by calling the widget's onChange function.
> 
> 3. Attribute: topic="<String>"
> 
> Get rid of the topic attribute.
> 
> 
> Rationale:
> 
> Widgets must ONLY use the specified property functions
> (Adapter.setPropertyValue, Adapter.getPropertyValue, Widget.onChange,
> Widget.onChange<Property>) to access the property values.
> 
> The implementations of these functions, including ALL event delivery
> functionality:
> 
> * are simply implementation details of the host,
> * are completely hidden from the widget, and
> * should not be controlled by widget.xml at all.
> 
> This includes:
> 
> * Whether the Hub is used, vs. some toolkit's existing
>     property management or notification system
> * If the Hub is used, what Hub topic/s are used
>     (Why does the widget care? It's dealing with properties here)
> * Whether the mash-up/tool enforces security policies that prevent access
>     to certain properties or topics
> * Whether the mash-up/tool provides features that allow end-users to wire
>     widgets together manually
> 
> Any mash-up or mash-up framework that uses the Hub for event notification
> at
> run-time must somehow (either automatically or by asking the developer for
> input) provide topics for delivery of these events. The exact topics used
> should not be under the control of widget.xml, which has no idea how a
> given
> mash-up framework works or what kinds of topics it finds convenient to use.
> 
> Property update events (as opposed to events that the widgets publish
> explicitly using hub.publish) are always implementation details of the
> framework or mash-up.
> 
> This reduces the complexity of the OAWM spec, albeit slightly, and allows
> application/framework developers the freedom to do what works best for
> them.
> 
> 
> BEST PRACTICE for mash-up and framework implementers:
> 
> For that use events to communicate any information, including property
> updates, use topic names that use reverse package notation starting with
> your organization name, e.g. "com.tibco.my.foo.bar" so as to avoid
> collisions between your events and those of other vendors and developers.
> 
> Regards,
> Howard
> 
> 
> --
> 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
> 
> _______________________________________________
> gadgets mailing list
> gadgets at openajax.org
> http://openajax.org/mailman/listinfo/gadgets



--
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 gadgets mailing list