Conference azur::mcc

    Keith,
    
    My my, well we are in trouble now.... (At least, I am). How would you
    go about implementing something which looks loke filtering ? Any
    suggestions will be appreciated.
    
    Are there any plans for this to be implemented in the not-too-far-away
    future ?
    
    Philippe. 

RE: .1

>    My my, well we are in trouble now.... (At least, I am). How would you
>    go about implementing something which looks loke filtering ? Any
>    suggestions will be appreciated.

  Philippe, the PM does do the With Qualifier processing, so filtering
  is done -- you realize that, right?  Your MM keeps returning all the data
  that is requested by the Verb, In-Entity and Partition arguments, and
  the PM ignores data which the With Qualifier would reject.

  But you need the With Qualifier passed to your MM - Right ?  What does
  your MM need use it for -- do you need to send the filter to the Entity ?

>    Are there any plans for this to be implemented in the not-too-far-away
>    future ?

  That, I do not know -- I'm sorry.  I'm not sure where it appears on the
  list of things for the next release either.

  Keith

    Keith,
    
    What the customer wants is to be able to send out the filter to the
    agent to avoid flooding the network with unnecessary data. As the
    filtering capability is a part of the CMIP protocol, it is not very
    efficient to let the PM do all the work.
    
    Philippe.

RE: .3

> What the customer wants is to be able to send out the filter to the
> agent to avoid flooding the network with unnecessary data.

I figured that was it, but I just wanted to make sure.  I know of no way
to get the With Qualifier to the MM.  Until an engineered solution has been
ECO'd into DECmcc, I'm sorry to say, the MM must return all the data for the
PM to filter  8(

I hope when the time comes, we (the toolkit) have the opportunity to get
some library routines in place to make the job of processing the filter
easier for the MM developer.  If a CMIP-like format is used, you can forward
it to the Entity ... but other MM developers will have to process the With
Qualifier manually.

/keith

    There are some basic issues within MCC as to how to implement
    filteringg
    and to define when to pass the scope and filter and where it
    should be applied. I put a note in this conference outlining the
    issues about 6 months back. Please read it to understand the
    issues.
    
    Keith - I think TNMP already has filter routines  they are the same
    ones as defined for Forwarding discriminators
    
    wally

Thanks Wally -- I'll read over the note you mentioned (have any idea which
one it is?)

> I think TNMP already has filter routines  they are the same
> ones as defined for Forwarding discriminators

This is what we want to hear!  Code Reuse - Great!

We should leverage off of any tools already available, and eliminate
as much redundant code as possible - I like it 8)

/keith

    Not mentioned in previous replies, referring to the ability for the
    "PM to do the filtering", is that the current scheme only works on SHOW 
    directives.
    
    Clearly a solution needs to be implemented in order to allow other (non 
    SHOW) operations, as well as the desire to save network bandwidth (an 
    important consideration in itself).

Re .6:
>
>> I think TNMP already has filter routines  they are the same
>> ones as defined for Forwarding discriminators
>
>This is what we want to hear!  Code Reuse - Great!
>
>We should leverage off of any tools already available, and eliminate
>as much redundant code as possible - I like it 8)
>

Code reuse is great but...

I am in charge of the filtering routines for TNMP (now called TeMIP).

We develop in fact 4 kinds of functionality. They are all based on OSI filters
(CMISFilter type) :

	1/ A MOTIF based window interface to set and modify filters (seen as
	object attributes within TeMIP).

	2/ A set of library routines to store/retrieve/update/delete/list/...
	pre-defined filters (using the MIR as repository )

	3/ A set of manipulation routine to create/build/read/decompose filters
	(to manipulate filters with as less as possible ILV knowledge ...)

	4/ A set of routine to validate and evaluate filters.

The reuseability problem is that our filters are used exclusively to filter
OSI events and so filtering routines will take in input a filter and an OSI
event and tell you if they match or not. Only part 2/ and 3/ can be reused
as such, 1/ can be extended without too much problem, but 4/ (which is the
most interesting part) would need a lot of improvements to be used for
directive filtering. 

Another point is that we have the requirement to be able to filter at least 25
events per second, which is not much to access the dictionary and be fully
generic...

You may also check with the Common Agent team, since they have implemented
a fully generic set of filtering routines based also on CMIS filters, but ...
using AVL as data encoding instead of ILV...

Regards.

Pierre.

RE: .8

Thanks for the information Pierre.  I don't know when or how the With
Qualifier stuff will be done -- but I hope its based on standards, such as
the CMIS filters, and made simple enough for MM developers to easily 
incorporate into their code.

/keith

    what kind of filtering routines are you interested in, the FCL also has
    some (since it is the one supporting with right now) that handles
    expression evaluation for the with clause.