|Subject||Re: Strategic Replacement for Services API|
> No one has to use the admin server just like no has to use theI do not want to fork any process - I want to do it from my process
> 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.
> An embedded application wouldn't ship it.How do I do backup then?
> That was actually what I proposed with one minor difference. SinceIn this case application that wants to talk directly to the admin
> 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.
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 loadableYes, I fully support this approach with one extension - add third
> 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.
entry point taking the XML directly and parsing it internally. Then I
can use that stuff in Java for applications that use embedded engine.