Subject | Re: [Firebird-Architect] Re: Strategic Replacement for Services API |
---|---|
Author | Jim Starkey |
Post date | 2005-07-29T17:23:54Z |
Roman Rokytskyy wrote:
module to be able to parse XML just in case you want to call it outside
the infrastructure it was designed for?
May I point out that if you're going to be calling the service modules,
it would be a lot easier for you to build the XML parse tree directly
(class Element in config) and skip the XML step altogether? Then
neither of you have to parse XML.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>>An embedded application wouldn't ship it.gbak? Or the dreaded services API (the admin server doesn't take it away).
>>
>>
>
>How do I do backup then?
>
>
>>An underlying question is how to map a operation name to a loadableLet me see if I understand this. You want to require every service
>>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.
>
>
>
>
module to be able to parse XML just in case you want to call it outside
the infrastructure it was designed for?
May I point out that if you're going to be calling the service modules,
it would be a lot easier for you to build the XML parse tree directly
(class Element in config) and skip the XML step altogether? Then
neither of you have to parse XML.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376