[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

842.0. "A challenge to all you Computer Science types" by TOOK::MATTHEWS () Tue Mar 26 1991 18:55

I have been spending my spare moments with a mental exercise of integrating
the OSI scoping and filtering into DECmcc so that the OSI agent PM can pass
on filters and scoping to subordinate OSI managed objects.

I haven't solved it yet, but I think I now have an appreciation of the
problem and what the issues are. I think that having multiple people
think about it and verify my understanding would be valuable so I am
putting what I think I know on paper for others to contribute to the
process.

First, OSI scoping is not the same as DNA wildcarding. They do the same
kind of thing but they are different in detail. Second, OSI filtering
is not the WITH clause. Yes, they are similar in concept but different
in detail. So if you think this is Passing wildcarding and the WITH
clause, it isn't.

The rest of this discussion is strictly how DECmcc interacts with
the OSI AGENT PM and subordinate OSI Objects. The intent is to work
out scoping and filtering in that context first, and then try to
find common ground with WITH and wildcarding.

For OSI, a base object is defined by a unique class object id pair that
is very similar to the EMA class instance pair. The scoping defines
the set of child entities of the base object to which the directive
may be applied. The filter uses assertions about the attribute values
of each of these objects to determine whether the directive is applied
to that particular object or not. 

In OSI the evaluation of the filter is done in the context of the target
object. The value of an attribute assertion for an attribute that is not
defined in the object's context is false. 

What makes this an interesting exercise is what do we do about attributes
which MCC maintains for an OSI object such as orphaned attributes and/or
augmented attributes. If we exclude them from participation in attribute
assertions, we can easily solve the problem. We can return an invalid
filter exception and/or strip them from the filter and pass down the
stripped filters to the target objects for evaluation. If however,
we intend to allow them participate in attribute assertions, how do
we simulate the filter evaluation so that we achieve the "consistent
myth" as Mark Sylor calls it.

We can't pass the filter down as is. The target object has no knowledge
of these attributes and their assertions would always be evaluated to
false. Well we could recognize them as augmented attributes and create
2 filters. The first filter would be a stripped filter to pass down to
the target object. The second filter would be the inverse stripped filter
retained by DECmcc for evaluation when the target object returns the
results of the request. The Inverse stripped filter would have all 
the appropriate true/false value substituted for all assertions of 
primitive attributes. The target object would expand the scope and
then filter the expansion based upon the stripped filter it was passed.
DECmcc would respond by further evaluating each expansion returned
from the target object by evaluating the Inverse stripped filter and
applying further filtering when it evaluates to false.

Yes, I know that we actually have to do this at 2 levels. The PM has
to do it for augmented attributes and the AM has to do it for 
orphaned attributes.

The algorithm would intuitively work for the GET function. However,
it will fail for create, delete, and action directives. The problem 
is that by the time we get a result to DECmcc we may have taked an
inappropriate action.

Another alternative is to perform the scope expansion and filtering
at the PM level in DECmcc. The obvious issue is performance. A more
subtle issue is whether expansion and filter evaluation in DECmcc
produces the identical result with what would result from the target
object.

Try your hand at the distributed algorithm and see if you can define
one that produces the correct result. Juan Valdez will award one month
of free coffee to the person who produces a correct non-trivial solution.

Solutions such as doing all expansion/evaluation at the PM, allowing
only augmented attribute assertions of base value augmented attributes, etc.
are already known. What is desired is that the augmented attributes can
participate fully in the scoping/filtering as if they were known to
the target object while not producing results that appear to be wrong
to a user of DECmcc. 

If you come up with a workable distributed algorithm that also handles
a system crash and recovers gracefully, Juan will kick in free coffee
for a year.

Wally Matthews aka Juan Valdez
T.RTitleUserPersonal
Name		DateLines
842.1no one said it was easy...TOOK::DENSMOREDirty deeds done dirt cheapWed Mar 27 1991 15:425
    Just to make it more interesting, consider the case where the filter
    is an OR of an attribute in the object and an attribute maintained by
    DECmcc (orphaned or augmented).
    
    						Mike
842.2why in the PM?TOOK::CALLANDERWed Mar 27 1991 16:3411
I know in the past we have had a tendency of saying "well the PM has a full
view of, and complete access to, the system; let's put it there."

Well here is a PM person telling you to find an FM!

Remember that FMs can call other FMs as well as AMs. The only thing they can't
do is call a PM; so since we can have multiple PMs...it would be nice if the
functions could be centralized in an FM (which could then be capable of 
handling augment/orphaned attributes and other such stuff).

jill
842.3I'll do anything for caffeine...ULTMAT::BELANGERA ROSE by anyother name, would not be manageableThu Mar 28 1991 11:2746
    
    It would be nice if as a scope/filter combination was passed to the
    managed object that the augmented and orphaned information could also
    be passed.  The problem with this is that filters are executed on
    scoped objects and unnecessary information would have to travel.
    
    Another option, might be to perform whatever scoping at the various
    levels.  Note though that the PM may know about augmented attributes
    but an FM is responsible for them.  The FM should deal with the
    scoping/filtering of augemented attributes (just like the AM deals with
    this processing for orphaned attributes).  If at each stage the
    scope/filters were dealt with for attributes which were known (defined
    by) the level and all other evaluations of scope/filter for unknown
    attributes were considered to evaluate to TRUE, then the set of managed
    objects could be reduced as we move down the mcc_call hierarchy.  As an
    example:
    
    	we have an FM which defins an augmented attribute and an AM which 
    	defins an orphaned attribute and a managed object with any number
    	attributes
    
    	If a request for a PM is passed to the FM with a scope and filter
    	which identifies the augmented attribute as well as the orphaned
    	attribute and also one for the managed object.  The FM assumes that
    	the scope/filter for the ophaned and managed object attributes
    	evaluate to true and only deals with the augmented attribute.  It
    	uses the scope/filter for the augmented attribute to obtain a set
    	of managed objects which evaluate to true for the augement
    	attribute.  The FM strips off the parts of the scope which deal
    	with the augemented attribute an make an mcc_call to the AM with
    	the set of managed objects (or a separate call for each managed
    	object).  The AM makes the same assumption about the scope/filter
    	for the managed object attribute as the FM did for the orphaned and
    	managed object attributes (ie: they evaluate to TRUE).  The AM uses
    	the scope/filter for the orphaned attribute to select a set of
    	managed objects from the set the FM supplied to arrive at a set of
    	managed object which have been scoped/filtered for both the
    	augmented and orphaned attributes.  The AM strips off the parts of
    	the scope/filter it received an sends the request(s) to the set of
    	managed objects it just scoped/filtered.  The resulting replies
    	from the managed objects "should" come from the set of managed
    	objects which fulfil the original scope/filter supplied to the FM.
    
    Now, how this fits into the WITH and WILDCARD, I have no idea.
    
    ~Jon.
842.4Reply to the intuitive solutionTOOK::MATTHEWSThu Mar 28 1991 13:1138
    This is reply to .3
    Assume that the base object has a child class of foo and 1000 instances
    of the foo class. Suppose there is an augmented attribute for foo, that
    means there are 1000 values associated with attribute assertion using
    that attribute. 
    
    First, OSI provides no mechanism for passing in augmented attribute
    values. Second, even if it did, who would want to pass in 1000 values
    for potentially complex structure attributes and along with each value
    you need to identify which instance the value is for. 
    
    If you assume that what is being passed down through the DECmcc levels
    apply only to the base object, your intuitive algorithm of peeling the
    layers as you go works quite well. However, if you assume OSI scoping
    what you are potentially passing down is a pointer to somewhere in the
    entity containment structure and asking for the operation to apply to
    some subset of the child entities of that base object. What you peeled
    off at the upper layers was the augmentation of the base object and
    not the augmentation of its children (recursively defined). Yet, OSI
    has it specified that scoping and filtering is recursively defined
    to apply (potentially) to the base object and all its descendents.
    
    This makes the peeling of the onion, a much more complex operation.
    That is the object of the challenge. Define an algorithm that can
    be applied at the appropriate levels of MCC that conceptually
    peels the layers for all the descendents for all the augmented
    values that apply at that level.
    
    I think as you appreciate the problem more, you see that it is far
    more complex than the intuitive view. I said that in the original
    challenge that solving it for the base value was an already
    understood solution but that we need to extend the solution to
    the descendents also IF we aspire to be fully OSI conformant.
    
    It also points out that blind acceptance of OSI as it is defined
    prevents us from doing useful things like augmentation of objects.
    
    wally
842.5OSI defines generic filters but also some specific restrictions sometimes...RIVAGE::LAVILLATFri Mar 29 1991 04:0528
Re .-1

>   It also points out that blind acceptance of OSI as it is defined
>    prevents us from doing useful things like augmentation of objects.

You maybe rigth there. I would rather express that by it prevents us from using
useful things like augmented or orphaned attributes within filters.

I think one should not forget that even if OSI defines very general filters, it
also sometimes defines (like for Event/Alarms filtering) what specific 
attributes can be used for filtering (and it is sometimes very restricitive).

Another thougth : can we assume that both PMs, FMs and AMs are able to recognize
wether a specific attribute is :
	- not defined for the current entity
	- defined but augmented
	- defined but orphaned
	- 'normal'

In this case each of them could take the appropriate action for each assertion :
a possible action could be ignoring the assertion if it is not able to handle 
it. 

I know this is a *very* partial idea, just to add my two �

Regards

Pierre
842.6clarification on capabilitiesTOOK::CALLANDERFri Mar 29 1991 09:4518
Maybe we should clear something up here. There is no way, from the data in 
the dictionary today, for any module to determine which attributes are
orphaned or augmented. The only means to a PM or FM to figure it out
if for the module to determine which
partition the attribute belongs in (this is in the dictionary) and then
to make a request for the attribute. 

Even then it isn't so simple. What will happen is:
if they use a call_function and the partition is supported by an
AM then the Control_FM will pass it through; if they use the call_access and
it isn't supported by the AM then they will get a dispatch entry not found
error. In either case it isn't real straight forward. The only one who knows
if it is augmented or orphaned is the AM itself responsible for supporting
the entity class.

The thing is that a PM or FM should have to care. They simply make the 
call_function and get the value, regardless of source.
842.7TOOK::DITMARSPeteFri Mar 29 1991 10:085
clarification of .6's clarification on capabilities:

>The thing is that a PM or FM should have to care. They simply make the 
                                    ^
                                   not
842.8rewrite MCC in CLOS or SMLRANGER::PRAETORIUSface to face to face with dualityFri Mar 29 1991 14:3936
     While I won't claim to be a computer science type, here's (what some might
consider) a computer science type of answer:

	if A calls B
	and predicate p must be evaluated in the context of A
	but B needs the value of p (for an object derived in B's context)
	then why not encapsulate the evaluation of p in A in a lexical closure,
	pass that closure to B
	and evaluate it there
	(where A is the PM or FM
	B is the AM
	and p is the test of the augmented or orphan attribute)

Answers to why not might be:

	no good equivalent to a lexical closure can be cobbled up inside MCC

	MCC's framework provides no good way to pass such a thing

	it might be inefficient

	it might not really solve anything

(but I'm no MCC expert).

     Or, in English:

	would it work to have the AM call back the FM or PM and have it
	test the attribute?

This could be nonsense, but what do you expect from somebody clearly identifying
themself as not a computer science type nonetheless providing a computer science
type answer?
								randomly,

									RP