Subject Re: Strategic Replacement for Services API
Author Roman Rokytskyy
> No one has to use the admin server just like no has to use the
> services API. Anything that can be from the administration server
> or services API can be done directly on the host machine with
> command line utilities. Really.

I do not want to fork any process - I want to do it from my process
(read Java).

> An embedded application wouldn't ship it.

How do I do backup then?

> That was actually what I proposed with one minor difference. Since
> the XML must be parsed to know what service to call, it makes more
> sense to pass the XML parse tree than the XML string.

In this case application that wants to talk directly to the admin
module would have to link with our parsing library. Add two methods -
one taking parsed tree, one taking XML and parsing it internally.

> An underlying question is how to map a operation name to a loadable
> module. I'm inclined to argue that the admin server should load
> everything it finds in a particular directory, asking each module
> what services it implements. Each service would export a single
> interface with two entrypoints, one that returns a list of service
> names support and the other the "execute" method.

Yes, I fully support this approach with one extension - add third
entry point taking the XML directly and parsing it internally. Then I
can use that stuff in Java for applications that use embedded engine.