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
> >
> >_________________________________________________________________
> >ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com