[OpenAjaxGadgets] Remove <property topic="">

Jon Ferraiolo jferrai at us.ibm.com
Tue Apr 14 09:09:43 PDT 2009


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/gadgets/attachments/20090414/b4736971/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/gadgets/attachments/20090414/b4736971/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic02458.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/gadgets/attachments/20090414/b4736971/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/gadgets/attachments/20090414/b4736971/attachment-0002.gif 


More information about the gadgets mailing list