PATCH_ADDED and PATCH_REMOVED

[lov]

In addition to the PATH_CHANGED notification, it would be useful to have notification when a new address has been added or removed.

[mrRay]

howdy-

my apologies, the proposal doesn't make this clear enough- i've modified the text slightly to reflect the original intent, which is to lump path changes, additions, and deletions into the single PATH_CHANGED notification.

i certainly don't mind adding explicit notifications for adding/removing paths if the general consensus is that this would be a welcome addition- what do other people think about it?

[lov]

ah, sorry, my bad! +1 for using a single method for all of "changed" related stuff and keeping things simple as can! ;)

[jcelerier]

Shouldn't this go in "upper" levels of the specification like proposed in #25 ?

I my library I experimented with the following :

• PATH_CHANGED which follows the spec.
• PATH_ADDED
• PATH_REMOVED
• ATTRIBUTES_CHANGED which is an aggregate of multiple attributes (for instance if you want to refresh both the value and the range of an object but not its whole tree).

And their plural forms which contains an array of the data of the aforementioned messages :

• PATHS_CHANGED
• PATHS_ADDED
• PATHS_REMOVED
• ATTRIBUTES_CHANGED_ARRAY < the name should change to be more homogeneous with the others but I cannot find something that conveys the meaning properly

[lov]

Shouldn't this go in "upper" levels of the specification like proposed in #25 ?

Yeah, you know my opinion from there ;)

[jcelerier]

Rethinking on this, the 'plural forms' was a dumb idea, it's much simpler to just send a json array directly at the root level if one wants to send multiple commands at once.

Also, I think that, just like a client would have to enable value streaming with the ?LISTEN=true query, receiving path changes should be conditioned to the client first requesting it.

Maybe something like ?STRUCTURE_LISTEN=(true|false) ? Or ?PATH_LISTEN, maybe ?

What I am not sure of, is, should this be a per-path attribute (like ?LISTEN), or a global attribute for the whole tree ? (I don't personally see the need for enabling this only for some paths and would rather have it be global.)