[OpenAjaxGadgets] [OpenAjaxIDE] Property onChange notification events

Tue Apr 7 02:56:25 PDT 2009

(I would leave it on Hub)
hw

On 4/6/09 10:42 AM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:

> 
> 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).
> 
> Jon
> 
> 
> 
> 
>                  
>              Rich
>              Thompson/Watson/I
>              BM at IBMUS                                                   To
>              Sent by:                  "gadgets at openajax.org"
>              gadgets-bounces at o         <gadgets at openajax.org>,
>              penajax.org               "ide at openajax.org"
>                                        <ide at openajax.org>
>                                                                         cc
>              04/06/2009 06:12
>              AM                                                    Subject
>                                        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??
> 
> Rich
> 
>                  
>  From:  Howard Weingram <weingram at tibco.com>
>                  
>  To:    "gadgets at openajax.org" <gadgets at openajax.org>, "ide at openajax.org"
>         <ide at openajax.org>
>                  
>  Date:  04/06/2009 06:55 AM
>                  
>  Subjec [OpenAjaxIDE] Property onChange notification events
>  t:              
>                  
> 
> 
> 
> 
> 
> 
> 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.
> 
> _______________________________________________
> IDE mailing list
> IDE at openajax.org
> http://openajax.org/mailman/listinfo/ide
> 
> _______________________________________________
> gadgets mailing list
> gadgets at openajax.org
> http://openajax.org/mailman/listinfo/gadgets
> _______________________________________________
> 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