Re: event subscribe operation SET-PROPERTY ?

Joel, 
When I serched my mail archive, I only found one email that I might unfortunately missed and that mentioned the SET-PROPERTY, as I attached at the end of the email, though my archive may be not so complete.
When I checked the email, I still could not find enough reasons that we, at current time, shall roll back a long way to pick up some  things that seems not so fatal to us. I'm also just a little worried that, there might leave serious inconsistence problems if we are too at will to make such crossing document changes at current stage. 

thanks,
Weiming

----- Original Message ----- 
From: "Joel M. Halpern" <[email protected]>
To: <[email protected]>
Sent: Saturday, October 14, 2006 10:24 PM
Subject: Re: event subscribe operation SET-PROPERTY ?


This was discussed extensively on the list.
The SET-PROPERTY / GET-PROEPRTY mechanism was 
actually introduced to get around a completely 
different set of problems.  After examining it, 
we realized that it was a good way to solve 
sseveral problems, including alias targeting and event subscription.

The alternative for trying to create identifiers 
for all of these things in the regular SET / GET 
space was a real pain.  And the semantics were quite misleading.

Yours,
Joel M. Halpern

At 09:50 AM 10/14/2006, Wang,Weiming wrote:
>I havn't noticed this arguement till recent days 
>when I'm trying to write some events xml for FE 
>Object. I think Fenggen has raised a very important question.
>
>I'd like to make a brief recall to the history 
>related to this event subscription issue in the 
>protocol team work in recent years.
>At the very begining, there were two thoughts 
>regarding how to subscribe an event, one was to 
>take a specific message or operation type called 
>subcribe/unsubscribe for the purpose, the other 
>was to ask event definitions to take a flag as a 
>subscription/unsubscription flag, then to 
>configure the flag to sub/unsub the events. 
>After a long discussion, it has reached a 
>consensus that a subcription flag will be more 
>efficient and be the prefered one. Hence, the 
>protocol has always followed the consensus till now.
>
>The SET-PROPERTY actually takes the same scheme 
>as to define an operation type specifically for 
>subscribe/unsubscribe. I'm not sure why it comes 
>this idea again. The protocol document might be 
>a little embarassed if it should be  repaired in this way right now.
>
>Thanks,
>Weiming
>
>----- Original Message -----
>From: "Joel M. Halpern" <[email protected]>
>
>You are right about SET-PROPERTY and
>GET-PROPERTY!  Protocol Team, is that being added
>to the protocol document.  (This is not a recent change.)
>
>I am not sure I understand the other question.
>A given event definition can have only one event target.
>An event definition is the event name, the event
>target, the event Condition (which describes the
>specific condition under which the event is
>triggered) and the event Report (which indicates what is reported.
>A given definition has a single target, a single
>condition, and a single reports (which has a list of fields to report.
>We do not need "eventTargets" or
>"eventConditions", because each event has one target and one conidition.
>
>If we had allowed multiple conditions in an event
>definition, then the occurrence of the event
>would have to have some way of indicating which
>condition had occurred.  Similarly, if there
>could be multiple targets we would need to
>indicate which target had detected the
>problem.  Withthe current structure, that problem does not arise.
>
>
>At 01:40 AM 9/29/2006, Jia Fenggen wrote:
> >I notified in model draft when one wants to
> >subcribe to an event,he uses SET-PROPERTY
> >operation and use the path composed of event
> >base id plus event id,here is a problem because
> >we haven't defined operation SET-PROPERTY in
> >protocol draft,and even a broader question,how
> >should we do to get and set LFB element
> >properities,how should the path be used,if I
> >misunderstand something here,I am sorry.
> >And another question,because i am not an xml
> >expert,i don't know why we not define <eventTarget> element as follows:
> ><eventTargets>
> >   <eventTarget>
> >      <eventField>..</eventField>
> >      <eventSubscript>..</eventSubcript>
> >   </eventTarget>
> >   <eventTarget>
> >      <eventField>..</eventField>
> >      <eventSubscript>..</eventSubcript>
> >   </eventTarget>
> >    ...
> ></eventTarget>
> >and the same question to <events> Element Conditions declaration.
> >Yours,Fenggen






----- Original Message ----- 
From: "Joel M. Halpern" <[email protected]>
To: <[email protected]>
Sent: Tuesday, June 21, 2005 11:18 PM
Subject: Properties component selection (model and protocol)


> I have had several discussions (mostly with Jamal) about the details of the 
> properties approach that was discussed on the list earlier.  I am going to 
> add this to the model.
> Please shout on the list if any of what follows seems a bad idea.
> 
> One pair of issues affects the protocol more than the model.
> You may recall an earlier email that discussed the issue of using a flag in 
> the path to indiciate taht one wanted property information instead of 
> content information.  This introduced some odd ambiguities and confusion.
> So instead it appears to make more sense to introduce two new protocol 
> operations,
>     GET-PROPERTIES, and SET-PROPERTIES
> These will take paths and data as content just as GET and SET do.
> And remove the ambiguity about the path reference flag.
> 
> Unfortunately, I then found a further complication.  Some properties are 
> only a single value (in a structure, for inheritance).  However, some have 
> more fields than that.  Array properties have several fields.  Alias 
> properties have several fields, some writeable.  So this raises the issue 
> of access to elements of the property structure.  We could declare for a 
> read that one just gets the whole structure.  But we want to be able to 
> write certain property information.
>      Aside:
>      We could decide to give up on using properties for aliases, and that 
> would remove
>      all current writeable properties.  But it is reasonable to expect them 
> to return.
>      In fact, I want to use them again for events.  So we need writeable 
> properties.
> For writing, it is clearly necessary to be able to indicate which field or 
> fields within the property information one is trying to write.
> So we need another path flag.  This flag is valid only within a 
> GET-PROPERTY or SET-PROPERTY.  And is not valid on path information nested 
> within a path that has used this flag.  The flag indicates that this path, 
> and all nested paths within it are to be applied to the property 
> information, not to the base path for selecting property information.  (I 
> currently can not imagine needing such nesting, but prohibiting it seems wrong)
> While this flag does have some special cases, they are at least clear.  And 
> this allows for selecting components of proprty information.