On 11/17/2011 11:53 AM, Zane Bitter wrote:
On 03/11/11 17:04, Zane Bitter wrote:
> 2) Write a C++ agent reusing some of the Gofer code
>
> In this approach, we would create a 'Gofer' agent in C++ like an
> ordinary Matahari agent, then cherry-pick the existing plugin and
> dispatch code from Gofer and plumb it in.[1]
>
> The big unknowns with this approach revolve around the dynamic
> generation of schemata. In particular, how we would handle method
> arguments, which are statically typed[2] in QMF. (Programmatic
> generation of schemata in C++ is itself not that difficult.)
>
> Planned investigations:
> Jeff - Look into how we can reuse code in this scenario
> Zane - Look into how we can handle dynamically generated schemata
I've been diving back into the Gofer documentation again to have a look at this. To
recapitulate, the question was around how we would match up the dynamic nature of the
plugin implementation languages (Python, Ruby) with the fixed schemata that are required
by QMF.
Dynamically generating a schema is no problem, but there is no way to know the correct
types for method arguments. In fact, there is no way in general to even know the correct
*number* of arguments. On reflection, I think the way to do this is to have a single QMF
argument to each method called "args" (actually two, one for named args as
well). We could
pass this argument simply as a string in JSON as Gofer is doing now, or split it into an
FTABLE (QMF's dictionary/hash type) leaving the individual arguments in JSON format.
So
all Gofer methods would effectively have identical schemata.
I think that regardless of whether arguments are passed into the python layer as the
correct types or a as a JSON blob, we still need to account for argument types. Although
python uses late binding, methods may assume that arguments are typed as (at least),
str|int|float. So, even if the matahari plugin mimics the gofer JSON envelpoe, the
contents will still need to be typed (from a JSON perspective).
What if the gofer plugin container could be inspected for class and functions where each
function or class method would provide a signature? The signature would include the
method name and argument names and types.
This is not exactly pretty, but it is in keeping with the dynamic nature of the target
languages. We could special-case the Gofer agent in the Matahari shell to make accessing
it through mhsh a little tidier.
This brings me to another question: would we port the client-side Gofer libraries to use
the Matahari/QMF backend? I think that would be relatively easy, and certainly this
format
could be implemented without users accessing it through that API ever noticing.
No. The gofer client provides for a features that I'm 99% sure that qmf does not
support.
Primarily in the areas of, object constructors, authentication/authorization and
timeouts (perhaps others). Because of the differences in this functionality end-to-end, I
anticipated that one restriction of accessing gofer plugins with the matahari/qmf
environment is that user use the qmf client(s) and write agent plugins accordingly.
I should add that while the mhsh development work will give us a Python API to Matahari
that is a bit higher-level than the existing QMF API, we have nothing similar planned
for
Ruby. At a minimum we would need some way to call Gofer plugins from Ruby (that part
could
be based on the existing API), but it would be even better to be able to access all
Matahari agents over the same interface.
Thoughts? Jeff?
regards,
Zane.