| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2534.1 | My opinion, shout if I am wrong... | TAEC::LAVILLAT | | Thu Mar 12 1992 06:03 | 34 |
| Hello Philippe,
My 2 � :
>
> I've noticed that when I issues a GETEVENT <Class> * directive, there
> is no global entity wildcard resolution done by the PM. Does this mean
> that the AM has to handle it ? Or does the Event manager support
> wildcards ?
>
Yes the Event Manager supports global class wildcards.
> Subsidiary question : The mcc_event_put routine uses mcc_aes_match to
> find any pending threads waiting for events. If one aes has a shorter
> spec than the other The mcc_aes_match routine returns a "Incomplete
> specification" status, but set the match to TRUE.
>
> The question is : does the mcc_event_put routine consider that
>
> GLOBAL x CHILD Y matches GLOBAL x ?
>
By experience NO (and it is what it is supposed to do).
> mcc_aes_match should return TRUE .... Or is the return status
> considered to be more important ?
>
So, in this case YES.
Regards.
Pierre.
|
| 2534.2 | In this case, opinion == fact | TOOK::T_HUPPER | The rest, as they say, is history. | Thu Mar 12 1992 13:55 | 5 |
| RE .1:
All correct.
Ted
|
| 2534.3 | | CCIIS1::ROGGEBAND | _ �hili��e _ | Fri Mar 13 1992 03:56 | 26 |
| Thanks Pierre,
So I guess I have the following options :
1) Issue GETEVENT directives on all child entity classes (Will the
Iconic Map Notification Services do this, or do I have to set up alarm
rules ?) and support it for all child entities ;
Or
2)
- Support GETEVENT only on thje global entity,
- In my event sink, associate all events with the parent entity and
pass the child entity ID in the data
- When returning from GETEVENT, encode an out_entity which includes
the child entity . If I remember correctly from a discussion I had
with Jill Callander earlier in this notesfile, the number of CI pairs
in out_entity may be different from In_entity as long as out_entity
is the one to which out_p applies.
Is this correct or am I bending the rules ?
�hR.
|
| 2534.4 | solution 1 should work. | TAEC::LAVILLAT | | Mon Mar 16 1992 05:43 | 43 |
| Re .3:
>
> So I guess I have the following options :
>
> 1) Issue GETEVENT directives on all child entity classes (Will the
> Iconic Map Notification Services do this, or do I have to set up alarm
> rules ?) and support it for all child entities ;
>
It will, if you tell him to do so...
I mean, if you say NOTIFY domain foo events = (sink event)
the NOTIF FM will issue a GETEVENT class * [subclass * ]... sink event
for all the class/subclass that support it found in domain foo.
I think that you do not even have to specify the event name(s) if they
(the events) belong to the NOTIFICATION partition.
> Or
>
> 2)
>
> - Support GETEVENT only on thje global entity,
>
> - In my event sink, associate all events with the parent entity and
> pass the child entity ID in the data
>
> - When returning from GETEVENT, encode an out_entity which includes
> the child entity . If I remember correctly from a discussion I had
> with Jill Callander earlier in this notesfile, the number of CI pairs
> in out_entity may be different from In_entity as long as out_entity
> is the one to which out_p applies.
>
> Is this correct or am I bending the rules ?
>
Beurk. I prefer solution #1
Regards.
Pierre.
|
| 2534.5 | | TOOK::STRUTT | Management - the one word oxymoron | Tue Mar 17 1992 16:19 | 28 |
| It has been suggested, a while ago, but no detailed ECO or
implementation has followed, that there should be an addition
allowed to the In_Entity specification to permit a sort of ellipsis
in the entity.
This would permit something of the form (across the call interface, not
necessarily at the user interface, as the U/I support has not been
designed yet):
verb: GetEvent
entity: Node FOO ...
partition: whatever
What this would do is request any event in the nominated event
partition for either the Node FOO or for ANY (not every!) child entity
however far down the entity hierarchy. Clearly in this case, Out_Entity
is needed to qualify the event returned.
Also, this same scheme could apply to other directives too, with what I
hope is obvious results.
Support for this variation of wildcard would need to be put into the
AMs (at least). It is consistent with one of the forms of wildcard
(aka scoping) defined in CMIS, notably 'whole subtree', so it (or
something like it) should be implemented some day.
Please don't ask if it's going to be implemented in v1.2 - it's not -
it's just an idea right now.
Colin
|