[OpenAjaxGadgets] Property onChange notification events

[Howard Weingram]

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]
==========

Problems:

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.

    PROPOSAL:
    
    (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
    values.

    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
    behavior.

    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.

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