Here is a summary of issues that were mentioned in Emails since I came from
Atlanta. I want to make sure that we've addressed them all. So here is the
list, with the resolutions that the group has come up with.
Side comment: it is really awkward to keep track of issues in a text file, but
here it is.
Please review these issues carefully.
********
- Is it possible for me to declare an attribute of type Any in the mrl file?
This is not possible in the code that ISI sent to Gatech.
This actually can mean two things, and we need to support them both.
1) A new Type_Code to allow the specification of an attribute that can
hold any of the supported types. This means that a client can use any
of the set_xxx methods to specify the value, or use the generic set
method that takes an MM_Any as a parameter.
We need suggestions for the name of the new type code:
MM_Type_Any --> this one seems better.
MM_Type_All
2) The other meaning of the first statement is that we should
uncomment the methods that take MM_Any as parameters.
// MM_Any get (in MM_Attribute_Symbol key);
// void add (in MM_Attribute_Symbol key, in MM_Any value);
// void set (in MM_Attribute_Symbol key, in MM_Any value);
// void remove (in MM_Attribute_Symbol key, in MM_Any value);
I am assuming that Gatech will implement this methods.
********
- Since there can be a Rule_None in the Inheritance_Rule, do we need to
add this to the syntax of MRL?
* I will need to add this feature to the parser.
As Noi mentioned, if an attirbute does not get mentioned in the
plays_role inherits (x,y,z);
is_like inherist (a,b,c);
it is not inherited, so there already is a way to say no inheritance
(by not listing an attribute in the above lists).
********
- Since attributes can have types over those possible in Type_Code, can they
have a Type_None? How is this done in the MRL syntax? I thought it was
syntactically incorrect to give an attribute without a ": type" clause.
* Currently the parser won't let you express a Type_None.
Type_None is meant for Any's that are newly created and have no value.
Agreed, there should be no way to specify this in the MRL syntax.
********
- How do we encode hooks in the API? Has the API been extended for hooks?
* ???
Currently there is no API for installing hooks.
The idea is to support PRE and POST hooks for set, add, remove, reset
and get. This defines a matrix of 2x5. We might even want more than
5 different kinds of hooks.
One thing that came up during the meeting in Atlanta is whether each
cell in this matrix can have a single or multiple hooks. I think we
should support multiple hooks in each cell.
Another issue is whether we really need get hooks.
Somebody needs to come up with an API for installing and de-installing
hooks.
One important thing is that the hook installing and uninstalling is
not a CORBA service, so it is not declared in the IDL for the object
system.
When tyhe hooks are executed, they run in the server.
One possibility:
// there is a typedef in srv_info.h for Hook_Function
enum {MM_Pre, MM_Post} MM_Hook_When;
enum {MM_Get_Hook, MM_Set_Hook, MM_Reset_Hook, MM_Add_Hook,
MM_Remove_Hook, MM_Changed_Hook} MM_Hook_Type;
There could be the following methods for class
MM_Attribute_Def_Internal:
install_hook (MM_Hook_When when, MM_Hook_Type type, Hook_function fun)
uninstall_hook (MM_Hook_When when, MM_Hook_Type type, Hook_function fun)
Currently the object system invokes pre and post hooks for set, reset,
add and remove. There is currently no way to set the hook.
What needs to be done is the following:
- Implement API to set the hooks.
- Revise current code to be able to store and invoke multiple hooks.
- I think we should also add a Changed hook that gets invoked on add,
remove, set or reset, so that one hook can monitor all these
operations.
Can Kurt do this?
Let's agree on an API first.
******** Kurt's question.
I've a question relative to writing model server components and the
old MRL parser. It appears that the old MRL parser did not generate
code to deal with inheritance. Is this the case?
Inheritance between object instances in not declared in the MRL. THe
model server API provides the instanitate method to create an instance
of another object, and it is also possible to explicitly change the
is_like attribute.
HOWEVER, we discussed allowing the definition of inheirtance between
object definitions, like C++ class derivation.
I think the resolution here was to wait and see if we really need
this.
The documentation of the model server API is the idl file. Once we
finish changes to srv.idl, Pedro will generate a new manual.
********
Issue about creating libraries for the object system.
What is the resolution here, and who is doing anything about it.
Looks like we could have either two or three libraries:
2 Libraries: corba, non-corba
3 libraries: independent, corba, non-corba.
It seems that the two library idea is better.
What is required to create this libraries (Makefile modifications?,
can JK do this?).
********
Standard types in IDL.
No resolution here yet.
I think the current consensus is that if the application model need to
support the specification of constants, then we need to support all
basic types.
If we go this way, we need to update the definition of MM_Any.
We should upgrade to support this, but we should do all the other
stuff first (ie, get the parsers and object system working).
HOWEVER, we need to add booleans now. Volunteers?
********
There is an issue about overloading of the MM_Any_Internal.
Currently there is no overloading for the operator= for enums because
it collides with the other numerical values.
Let's get back to this issue after other things are resolved.
********
Issue with Orbeline locking up.
The problem is understood, and Ewald will modify the code to go around
it.
HOWEVER, we should update the IDL with the "oneway" keywords for all
the methods that currently return void.
Can JK or Kurt do this? Ewald will fix the other problems when we get
the files back to ISI.
********
Is the issue about the directory structures solved to JK's
satisfaction?
********
Marshalling of floats does not work on Orbeline, so, Kurt, use doubles
in the presentation model where float would have been appropriate.
Pedro Szekely
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292
Phone: 310/822-1511, Fax: 310/823-6714
URL: http://www.isi.edu/isd/szekely.html