Re: event subscribe operation SET-PROPERTY ?

Weiming,

1) I would rather we dont go back and rehash the accessibility of
properties at this time for the sake of time to get the RFC review. 
IMO, we screwed up by not having it in the protocol because it was
discussed on the concalls and list - so thanks very much to Fenggen for
catching it. 
To fix this i have opened an issue (#88) in the tracker so that it is
fixed in the draft. In retrospect thats what we should have done with
the properties (opened tracker issues)

2) On resource usage that you point out below:
IMO, one could live with threshold, eventHysteresis,eventHysteresis
being always present because they are as many of those as there are
events. And i dont see a gazillion events anywhere. The nasty one maybe
the 8 bits defined for base properties since that is present in every
element. 

cheers,
jamal

On Mon, 2006-16-10 at 13:41 +0800, Weiming Wang wrote:
> I seems more flexible to set an element called <property> to deal with the requierment. 
> A property element is just to assign an element id and the property datatype. In this 
> way, everything is united under one uniform Path-Data format and it also makes LFB 
> definition document more readable. Taking an examle as below:
>  <attribute elementID="1">
>     <name>foo1</name>
>     <property elementID="1">baseElementProperty</property>
> ...
> </attribute>
> <event eventID="1">
>     <name>foo2</name>
>     <property id="1">eventProperty</property>
> ...
> </event>
> 
> This also makes possible more than one kind of property type defined for the same element. 
> I just noticed that to mandate every element with one mandatory property just wastes lots 
> of resources. For e.g., for an event, in most cases, it is not necessary for event having 
> properties like threshold, eventHysteresis,eventHysteresis(I suppose a typo here), 
> eventCount as defined in mode draft p.68.
>