Roman Rokytskyy wrote:

>
>
>>I'm not sure we want to go through the pain and suffering of hammering
>>out utility APIs that we can live with in perpetuity, so I suggest
>>that the APIs beconsidered ad hoc and subject to change without
>>notice.
>>
>>
>
>Sorry, I object. People, especially those that use embedded Firebird,
>need that API to provide backup/restore functionality, user
>management, etc. in their applications.
>
>
>

Let's back up. The Services API is going to be supported totally and
completely. If you use that dog, everything will work just fine. The
APIs I was talking about are the internal APIs used by the various core
utilities, their command line front ends, and the Services provider.

The public API is the Services API. If you want release to release
stability, use that. If you want a callable version of a local utility,
you can use the callable core of the utility, but don't expect the API
to be invariant from release to release. In other words, the split
between utility command line front end and core backend is pragmatics,
not architectural.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376