> The way I read Jim on this is that the overall architecture does not
> necessarily have a 'server'. What sense has the 'Services API' or
> generally speaking 'server attachment' concept when there is NO
> 'server' implied (when for instance the whole thing is statically
> linked within the application executable) ?

Personally I have a problem when Services API is considered to be
server-related. It successfully works in embedded mode and I see no
reason to break it.

Currently Services API provides:

- user management
- database backup/restore
- database maintanence (gfix & Co.)

All these features make sense in all modes. So, the main difference
between call via Services API and isc_database_info is that you can
call it without attaching to the database first. Current API does not
make that distinction, and personally I would prefer to keep it this way.

I think that our main problem communicating with Jim is that we still
use term "server" referring to any attachment that does not need a
database and for Jim this is "a part of the process that accepts
socket connections and translates them into internal engine calls".
For Jim there cannot be "embedded server" since this is contradiction
in terms, for me personally this means only a library that exports
current ISC API and provides all capabilities that remote instance
has, however runs in the same process. So, most likely we have to
start using another word - "s/server/engine/g".

Roman