Re: Wrapping API in service program

Buck,

I think you're on the right track.  Many system APIs are necessarily
low-level.  Or follow a Unix naming convention - which is basically no
convention.  Or are geared toward C data types.  A wrapper around many
system APIs can often provide a simpler interface.  Also, a higher level
interface that incorporates calls to more than one system API can also apply
to many applications.

Regarding the idea of service program families, I think you're also on the
right track.  If a particular application requires the use of multiple APIs,
then it makes sense to combine them into a single service program.
Sometimes you'll want multiple procedures to reference variables which are
scoped to the service program.

It's kind of a balancing act.  On one extreme you could create a service
program for every procedure.  On the other extreme you could combine
unrelated procedures into a single service program.  It can waste CPU time
if you program must bind to multiple service programs upon initialization,
but it can waste memory if all your programs bind to only one service
program that contains a lot of procedures that are never used by the
application.

Nathan.

----- Original Message -----
From: "Buck Calabro" <Buck.Calabro@commsoft.net>
To: <midrange-l@midrange.com>
Sent: Wednesday, September 12, 2001 10:08 AM
Subject: Wrapping API in service program


> As I work with more and more APIs, I want to wrap them in my own
procedures.
> I want to make these procedures available to others in my shop; service
> programs seem just the ticket.  My first thought was to wrap each API
> "family" in it's own service program, so I'd have one service program for
> user spaces, one for retrieving program information, etc.  This seems a
fair
> balance because a single program will only need to bind to a few service
> programs in order to work.
>
> 1) Any contrary ideas?
> 2) Any practical experience to support/refute this plan?
>
> Buck Calabro
> Commsoft; Albany, NY
> Visit the Midrange archives and FAQ at http://www.midrange.com