resolve protocol for API operation map

[eirrgang]

A Context implementation needs to be able to read an element from a work specification that tells it the name of a function to call, the parameters to pass to that function (or to set on the resulting object), and the library that implements the function.

There are several possible protocols, each with downsides. Before the map, non-built-in operations caused a module import followed by a non-method function call (with either no arguments or arguments from element.params). This works fine for calling a constructor.

I'm currently trying to build a map of functions when the context loads the work specification. There are built-in operations specified by the API and implemented by the Context, and there are non-built-in operations that are specified by work elements that use a non-built-in namespace. At run time, the Context can look up functions to run in its map: self->operations->namespace->operation_name.

If operations implemented by the Context are provided as member functions, then the signature of functions has the Context as the first argument. This is probably useful, and may be worth formalizing whether or not operations are intended to map to Context member functions.

In another prototype, the WorkElement object was passed to the function implementing the operation for maximal flexibility in dispatching, but just passing the params ought to be sufficient as per the original design.

For even more flexibility, I tried calling the mapped function first with the params as an argument list, catching an exception if it failed, and trying instead with no arguments, then calling set_params(*args) as a member function of the returned object. This allowed me to let mapped functions be class names that could be used to construct objects.

For the moment, the simplest thing is probably to just make the mapped functions work with either zero arguments or arguments from the params list. If we want to use member functions or something, we can store lambdas or some other closure in the map to hide the extra arguments.

[peterkasson]

Not sure I entirely follow; if you're on track and happy, go for it. Otherwise perhaps walk me through it when we chat?

[eirrgang]

This goes deep into the Context-implementation API, with implications for what plugin development looks like and how well we support various aspects of the execution environment abstraction and API extensibility. Technical design issues include:

• to what degree do we want to tag or type operations and edges to help the puzzle pieces fit together?
• How should a gmxapi WorkElement best be generated for a plugin module?

This is probably a long-term issue targeted for much closer to 1.0, but it may generate or tie together task issues while collecting design conversation. I'll try to represent the ideas and issues more clearly with time.