API Design Question

[Shawn Devlin <sd...@recognia.com>]

Hello all,

I have an CGI based HTTP API (in Perl) to a database and I am now going 
to port to mod_perl. I am new to this kind of programming and I have a 
couple of questions. The platform is Linux.

My first thought is to break the API up so that there is a module per 
API call (there are some 70 calls in the API). My reasoning is that I 
can modify existing calls and add new ones without affecting everything 
else. Does this make sense or is it better to have the API as one large 
program as I have it now?

My second question pertains to Apache::DBI. I will ask it here but if 
there is a better forum to ask it please let me know and I will ask it 
there.  I want to use Apache::DBI in order to cache database 
connections. If I understand everything that I have read so far (and 
that might be a big if) the various modules should share the same 
database connections while running on the same Apache server. Is this 
correct? I.e. if the API functions 'foo' and 'bar' have both been loaded 
into the same instance of Apache and both use Apache::DBI then they will 
share the same database connection.


Thanks.

Shawn

-- 
This communication is intended to be received by the individual or
entity to whom or to which it is addressed and it contains information
that is privileged, confidential and subject to copyright of 
Recognia Inc. Any unauthorized use, copying, review or
disclosure is prohibited. If received in error, please contact me by
phone at 613-623-6159 or by email at mailto:sdevlin@recognia.com.

Re: API Design Question

[Per Einar <pe...@skynet.be>]

----- Original Message -----
From: "Shawn Devlin" <sd...@recognia.com>
To: <mo...@apache.org>
Sent: Friday, June 29, 2001 8:18 PM
Subject: Re: API Design Question



> What I like about this is I can add a new function without needing to
> disturb the existing code. Also, each function call is then
> self-contained. Currently, my existing API script is essentially a big
> switch statement.

I see the point in separating it. I do the same thing myself.


> My concern is that each handler links the .pm files so with 50 or so
> functions I will have 50 or so copies of the various .pm files in memory.

That's not quite right. In its simplest form, I can say that Apache gets one
copy of each module per *child*, not per file, so 50 files doesn't mean
you'll have 50 modules loaded. For example, if one child serves /api/foo,
and /api/foo loads API1.pm and API2.pm, those will stay in memory, so that
when the same child serves /api/bar, and /api/bar attempts to use API1.pm
and API2.pm, the perl interpreter will find out that these 2 modules have
already been loaded, and not reload them.

But if you use preloading, as you should do, you get even more benefit from
shared memory. If you preload your modules in starup.pl or with PerlModule
in httpd.conf, they'll stay shared in memory, thus reducing the memory
overhead.

Per Einar Ellefsen

Re: API Design Question

[Shawn Devlin <sd...@recognia.com>]

Adam Worrall wrote:

>>>>>>"SD" == Shawn Devlin <sd...@recognia.com> writes:
>>>>>>
>
>    SD> My first thought is to break the API up so that there is a
>    SD> module per API call (there are some 70 calls in the API). My
>    SD> reasoning is that I can modify existing calls and add new ones
>    SD> without affecting everything else. Does this make sense or is it
>    SD> better to have the API as one large program as I have it now?
>
>I'd have thought you'be best to put the API in a large module, and then
>make calls to it from mod_perl handlers. You oculd even write a generic
>handler which chose which function to execute based on the arguments.
>
>Having a module per function may start to do your head in :)
>
The bulk of the API is in 4 or 5 .pm files. My cgi script basically 
determines the call being made, vets the parameters, calls vaious 
functions in the .pm files, and then returns the result. The current 
format for the call is

server.com/cgi-bin/api.pl?command=foo&parm1=&parm2=

What I want to have is

server.com/api/foo?parm1=&parm2=

The module that handles foo would check the parameters, make it's calls 
to the various internal functions, and then compose and send the results.

What I like about this is I can add a new function without needing to 
disturb the existing code. Also, each function call is then 
self-contained. Currently, my existing API script is essentially a big 
switch statement.

My concern is that each handler links the .pm files so with 50 or so 
functions I will have 50 or so copies of the various .pm files in memory.



>
>Yes - when some Perl in an Apache child process executes DBI::connect
>(which has been overridden by Apache::DBI), it first looks in a hash of
>existing connections before opening a new one. Good news !
>
Thanks for the conformation.


Shawn