Dear Matt,
Thank you for your prompt response.
If I understand correctly, Athena works with Larch by making command strings (Text::Template?) and submitting it to Larch via XML-RPC.
So, it would be the best way, as you suggested.
> server.larch("grp = read_ascii('/path/to/xas/data')")
I understand you don't plan to expose (all of) "low" functions, too.
Well, that would be a large number of functions to expose, each needing error checking, and support for how to map the various data types. I think that would end up repeating nearly all of Larch and Python for the RPC interface. The "read_ascii" example might be possible, as it takes a string for a filename (then again, for RPC, is it obvious that files are accessible from the same path?). But if you want to do any data processing, you'd have to be able to handle more complex Python objects (dictionaries, lists, numpy arrays).
The main motivation for the RPC interface was so other languages (say, Perl) could run the Larch functions. For Demeter, having a "session" makes sense -- the GUI is an interface that wants to keep track of analysis steps and be able to apply functions on data in memory.
I intended to use Larch in loose-coupling (without knowledge of a Larch session status) with my app, so I have to go another way.
I guess it depends what you mean by "loose-coupling". The RPC interface supports using Larch from another language and/or from a different process (even different user account or machine). To use Larch from outside Python, some sort of RPC is needed. I can believe it could be better, but there have not been a lot of requests for that.
Maybe you can describe what your trying to do?
Cheers,
--Matt