Issue 3998: No Access to event filter form component (components-ftf)
Source: Open Networks Engineering (Mr. Jean-Christophe Dubois, jcd(at)one.com)
Nature: Uncategorized Issue
Severity: 
Summary: As the CCM spec is not giving any mean (or very little) to fill in the
filterable body part, no services are provided for a component to set its
event filters when sending or receiving events.

This seems to be a very usefull service to me for application such as:

- limiting the number of events emitted by a component based on a config
parameter (like messages with priority > config value can go out, other are
discarded. when the config value change at runtime the filter could also
change.
- filtering events received from a notification channel.

I agree that these 2 function could be achieve by user code in the component
but it means that unecessary events are passed between components and the
netwok load and CPU load is higher than necessary.

I guess the point I am trying to make is that using the notification service
without using filters and/or filterable body doesn't seem to make a lot of
sense.

What is the intend of the sepc on this issue?

Resolution: See issue 3938. rejected
Revised Text: 
Actions taken:
October 25, 2000: received issue
May 13, 2002: closed issue
Discussion: 

End of Annotations:=====
From: "Jean-Christophe Dubois" <jcd@one.com>
To: <issues@omg.org>
Cc: <components-ftf@omg.org>
Subject: No Access to event filter form component
Date: Wed, 25 Oct 2000 13:34:50 -0400
Organization: Open Network Engineering
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Type: text/plain;
	      charset="iso-8859-1"
X-UIDL: E3-e9>"i!!I\*!!PC/e9

As the CCM spec is not giving any mean (or very little) to fill in the
filterable body part, no services are provided for a component to set
its
event filters when sending or receiving events.

This seems to be a very usefull service to me for application such as:

- limiting the number of events emitted by a component based on a
  config
parameter (like messages with priority > config value can go out,
  other are
discarded. when the config value change at runtime the filter could
  also
change.
- filtering events received from a notification channel.

I agree that these 2 function could be achieve by user code in the
component
but it means that unecessary events are passed between components and
the
netwok load and CPU load is higher than necessary.

I guess the point I am trying to make is that using the notification
service
without using filters and/or filterable body doesn't seem to make a
lot of
sense.

What is the intend of the sepc on this issue?

Regards

JC