On 19/11/11 17:40, Russell Bryant wrote:
Based on my understanding:
On 11/19/2011 11:00 AM, Perry Myers wrote:
> I'm sure this has been covered before, but either I'm always forgetting
> or I never clearly understood the explanation.
>
> AgentX has a method foo(A, B)
> ConsoleX calls method foo(A, B)
>
> No issues so far, both Agent and Console are using the v1 schema for
> AgentX so all is well
>
> Scenario 1:
> -----------
> Now say that Agent1 has a schema change and does the following:
>
> Adds: foo(A, B, C)
> Adds: bar(D, E)
>
> ConsoleX is still running and calling foo(A, B)
>
> What happens? Does ConsoleX blow up?
As long as the agent was written to not require C to foo(), everything
keeps working. Otherwise, the ConsoleX will get a QMF exception.
> Scenario 2:
> -----------
> Let's say that instead of the above, ConsoleX adds the following:
>
> Adds: foo(A, B, C)
> Adds: bar(D, E)
>
> But AgentX still has schema with only foo(A, B)
>
> If ConsoleX makes a call to foo(A, B, C) will AgentX process it and just
> ignore the new parameter, or will it just fail gracefully, or will it
> error and stacktrace the Console
It will still work.
> Same question if ConsoleX calls bar(D, E) (new method vs. existing
> method with new parameter)
ConsoleX gets a QMF exception.
> Finally... the above covers Consoles that are calling methods somewhat
> statically. But what about the matahari shell, where we'll be
> presenting remote Agent schema more dynamically to the user?
When mhsh is being run interactively, the methods and arguments
presented will only be the ones currently used by the agent. The shell
will be pulling the schema from the agent to determine what it has. Any
QMF console can do this if they want to.
If someone were to use it in a scripted manner, then the same results as
discussed above apply.
Related wiki page:
https://github.com/matahari/matahari/wiki/Schemas
The concept of the schema changing on the fly is a bit of a red herring;
I don't believe there is any way for the schema to change without the
console being aware of it. The question is whether consoles written
against old schemas can handle sending the same data to an object with a
new schema (i.e. what happens when the console and the schema don't match).
Having tested this out, I can confirm that it works as Russell describes
for C++ consoles. Method arguments are just a map of names to
parameters; there can be more or fewer or just different arguments and
it is up to the agent/console to deal with it. The same applies to
output arguments.
However, it does *not* work in the Python API, where the number of
arguments provided must exactly match the schema. I have raised an issue
against Qpid in JIRA to fix this:
https://issues.apache.org/jira/browse/QPID-3653
Output arguments work correctly in both C++ and Python.
cheers,
Zane.