Haven't had time to try the build, will try tomorrow.
I agree the subdirectories and files should have consistent names. Monday is
a good day to do it, as far as I am concerned. Pablo? Ewald?
Regarding the complicated question, I am not sure I completely understand the
problems you describe.
MRL allows you to build very complicated networks of objects with no problem
because you can store the same object in different attributes of different
objects. MRL is a bit like lisp in the sense that all objects are actually
pointers to the objects, but as a programmer you don't see the pointers.
Here is a quick and dirty MRL and C++-ish code that builds something like what
you seem to want. In any case, it is a graph-like structure.
Object Task {
attribute task_conection : Task_Connection;
};
Object Interaction_Technique : Task {
};
Enum Ordering {Unrestricted, Sequential};
Object Ordering_Constraint {
attribute before: Task;
attribute after: Task;
};
Object Task_Connection {
attribute sub_tasks: sequence<Task>;
attribute primary_ordering: Ordering;
attribute ordering_constraints: Sequence<Ordering_Constraint>;
};
// Here is some C++ pseudo-code for making the object system build the
// desired structures. I am not sure the syntax is correct.
//
void main () {
MM_Object T0, I1, I2, I3, C1, OC1;
T0 = server->instantiate(MM_Task);
I1 = server->instantiate(MM_Interaction_Technique);
I2 = server->instantiate(MM_Interaction_Technique);
I3 = server->instantiate(MM_Interaction_Technique);
C1 = server->instantiate(MM_Task_Connection);
// So here is the task tree with unrestricted ordering.
T0.Set(MM_Task_task_connection, C1);
C1.Set(MM_Task_Connection_primary_ordering, Unrestricted);
C1.Add(MM_Task_Connection_sub_tasks, I1);
C1.Add(MM_Task_Connection_sub_tasks, I2);
C1.Add(MM_Task_Connection_sub_tasks, I3);
// Now let's say you want I2 to come before I3.
MM_Object OC1;
OC1 = server->instantiate(MM_Ordering_Constraint);
OC1.Set(MM_Ordering_Constraint_before, I2);
OC1.Set(MM_Ordering_Constraint_after, I3);
C1.Add(MM_Task_Connection_ordering_constraint, OC1);
}
Does this answer question 1?
The answer to questions 2 and 3 is NO in both cases, but ....
No, because the model objects do not store any run-time state, so the model
objects cannot be used to store anything that is going on during the execution
of an interface. Runtime state is stored in Amulet objects which are created
from the model objects. I can explain in more detail
Corba performance issues are addressed in one of two ways:
- Use the pure C++ version of the object system (cpp) in which the API is
identical to the Corba version, but that doesn't use Corba.
- Collocate the client and the server so that they coexist in the same address
space. This solution uses Corba, but is optimized because Corba calls become
method calls.
So, in both cases client code is really executed in the server process,
short-cutting communication, and improving performance.
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