[OpenAjaxGadgets] [OpenAjaxIDE] Property onChange notification events

Rich Thompson richt2 at us.ibm.com
Tue Apr 7 04:28:13 PDT 2009

Might want to define an interface the runtime has to make available 
(likely exactly matches HubClient) such that widgets can have a 
well-defined way to publish events as well as doing dynamic subscribes.

Rich Thompson
IBM T.J. Watson Research Center / Hawthorne, NY

Jon Ferraiolo/Menlo Park/IBM
Rich Thompson/Watson/IBM at IBMUS
"gadgets at openajax.org" <gadgets at openajax.org>, 
gadgets-bounces at openajax.org, "ide at openajax.org" <ide at openajax.org>
04/06/2009 01:46 PM
Re: [OpenAjaxGadgets] [OpenAjaxIDE] Property onChange notification events

Regarding explicit mention of OpenAjax Hub in the spec, it seems like we 
should be able to find a way to describe the necessary behavior (i..e, 
message transmission and reception) without having to mention a particular 
technology (i.e., the Hub).


Rich Thompson/Watson/IBM at IBMUS 
Sent by: gadgets-bounces at openajax.org
04/06/2009 06:12 AM

"gadgets at openajax.org" <gadgets at openajax.org>, "ide at openajax.org" 
<ide at openajax.org>

Re: [OpenAjaxGadgets] [OpenAjaxIDE] Property onChange notification events

I agree that a widget only has its subscribe handler invoked if someone 
outside the widget causes the property value to be updated (actual value 
change). Likewise, an event is only published if the widget causes the 
property value to change. It also is reasonable to have an overall 
namespace for topics with the default being the widget's namespace. 

Reading through the quoted portions of the spec was tough with my spec 
writer hat on. The reason is that I firmly believe specs should be loosely 
coupled unless the specified functionality can not be achieved with a 
loose coupling (rare). This section explicitly requires use of the Hub 
spec without any real need for that requirement (i.e. any event 
distribution mechanism would be fine, the Hub is an example). Is there a 
reason for such tight coupling other than both are being defined under the 
OAA umbrella?? 


Howard Weingram <weingram at tibco.com> 
"gadgets at openajax.org" <gadgets at openajax.org>, "ide at openajax.org" 
<ide at openajax.org> 
04/06/2009 06:55 AM 
[OpenAjaxIDE] Property onChange notification events

I have some questions, comments and proposals.

The IDE spec currently says the following:

The publish attribute. Boolean. Default value is 'false'. If true, 
that the user agent should publish an event on the OpenAjax Hub whenever 
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 
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 
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 
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
   actually changed?

   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?

       PROPOSAL: NO.

   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

IDE mailing list
IDE at openajax.org

gadgets mailing list
gadgets at openajax.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/gadgets/attachments/20090407/e54ab3d9/attachment.html 

More information about the gadgets mailing list