Subject Re: [Firebird-Architect] Re: Strategic Replacement for Services API
Author Jim Starkey
Roman Rokytskyy wrote:

>I did not talk about the server, but about the embedded engine. The
>one that is used in applications without any server, that are shipped
>on CDs, etc. to the end users, not administrators. There is not
>Firebird server, there is no admin server, there is no SSHD.
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.

>>Postulating a security problem because of a buffer overflow before the
>>code is even written is not exactly a demonstration of good faith.
>That's not about good faith for the project, but about the good faith
>in regard to people that want to embed Firebird in the application. If
>that happens that will strike our customers, not us in the first place.
An embedded application wouldn't ship it.

>Why don't you define generic interface to each admin module that might
>have only one method execute(char*):char* where the XML is passed and
>XML is returned back and some more calls like which calls it works
>with, etc. Then your admin server loads these modules the same way
>your Y-valve loads providers and dispatches the requests to the code.
>This approach leaves the possibility for application developer to talk
> to the admin module directly without need to start any server.
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.

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.


Jim Starkey
Netfrastructure, Inc.
978 526-1376