Dmitry Yemanov wrote:

>"Ann W. Harrison" <aharrison@...> wrote:
>
>
>>My suggestion is that we separate each of the utilities into a backend
>>shared library and a front-end program that calls the library. The
>>shared library uses the services API as its interface. The program is a
>>very thin layer that provides a user interface for the library.
>>
>>
>
>This is more or less something I've been thinking about myself. My full
>support to this idea.
>
>
>
>

I like the idea of a class encapsulation of each utility, but I'm not
comfortable the idea of packaging the common backends in shared
libraries. The problem is version skew. It is often very useful to
have different versions of various utilities floating around,
particularly when someone has an archive of older databases. Split each
utility into a front end executable and backend shared library means
that two files must be copied when saving an older version of the
utility. Worse, the back end libraries will have the same (immutable)
name. While so operating systems have facilities to find overloaded
library names by version number, not all do, nor are these easy to
administer. It also means that the services provider itself requires a
set of other libraries, complicating the process of saving archival
service providers.

Splitting the utilities presents even greater problems if we encapsulate
the utility core as a C++ class. I'm not sure we even want to go there.

On the other hand, the benefits of a shared utility back end are
minimal, having no effect but to reduce the kit size by an amount equal
to the combined sizes of the prospective libraries, a little less than
the combined sizes of the current utilities. Compared with the full
size of a kit, the savings is insignificant.

I see benefit to a class encapsulation, but I think the administrative
costs (and likely bungling) of split utilities overwhelm the meager
benefits.


[Non-text portions of this message have been removed]