Re: event subscribe operation SET-PROPERTY ?

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