Re: event subscribe operation SET-PROPERTY ?

Jamal,

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email protected]>

> 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)
do you mean to fix it in the protocol draft or in the model draft? I suppose the protocol draft still leaves open chances to fix some thing if we think it is necessary. I just think the SET-PROPERTY is not necessary and we may be able to adopt other choice. 
> 
> 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. 
It still appears awkward some for some events reflecting status changes only.

thanks,
weiming

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