[OpenAjaxGadgets] Property onChange notification events
weingram at tibco.com
Mon Apr 6 03:51:47 PDT 2009
I have some questions, comments and proposals.
The IDE spec currently says the following:
The publish attribute. Boolean. Default value is 'false'. If true, indicates
that the user agent should publish an event on the OpenAjax Hub whenever the
value of the property changes. Attribute 'topic' indicates the name of the
topic that is used when that event is published. 2009-02-23 Jon: I updated
the description [MASHUP]
The subscribe attribute. Boolean. Default value is 'false'. If true,
indicates that the user agent should subscribe to property change events on
the OpenAjax Hub for the topic indicated by the 'topic' attribute, and
update this property to the new value that is received. 2009-02-23 Jon: I
updated the description [MASHUP]
The topic attribute. String. Defaults to NULL. Identifies the topic name
that is published to (if 'publish' is true) and/or subscribed to (if
'subscribe' is true) on the OpenAjax Hub. If the attribute is not specified,
or is NULL or the empty string, and if 'publish' is true or 'subscribe' is
true, then the value of the 'name' attribute is used as the topic name.
(Note that providing a value to 'topic' has no effect if 'publish' is false
and 'subscribe' is false.) [MASHUP]
1. This appears to state that the property name must be used as
the default topic.
Topics SHOULD be namespaced. Namespacing ensures that different
organizations can specify their own sets of topics without
causing endless collisions.
Using a single-token topic like "accountNo," as the spec
appears to require, is GUARANTEED to result in topic name
collisions between different families of widgets, balkanizing
the application space, causing a lot of trouble when widgets
receive incompatible data on overly generic topics, and greatly
reducing the usefulness of the standard.
(If property names are used to implicitly define topics),
widget.xml MUST specify a topic prefix that namespaces
these implicitly defined topics.
2. Does a change notification get sent each time setPropertyValue
is called, even if this does not change the property value?
(i.e. can SetPropertyValue be used to affirm an existing value?)
Or does a change notification only get sent if the value has
To determine whether the new value is different from the old
value, setPropertyValue would need to traverse the value, which
might be a complex object, and directly compare old and new
PROPOSAL: setPropertyValue ALWAYS forces a change notification
to be published, even if the data did not actually change.
3. If subscribe and publish are both true, we need to specify the
a. Does the widget see its own updates?
b. If the answer to (a) is "yes", then does the widget
distinguish its own updates from others' in some way?
If not, then because of #2, there will be infinite loops.
4. If an update event arrives and updates the property value, this
change MUST NOT cause another update notification to be
published. Update notifications are published only when the
setPropertyValue function is called explicitly.
The expected behavior of properties & their update events needs to be
clearly defined in the specification to avoid different vendors from
implementing mutually incompatible behavior.
Your thoughts welcome.
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