Re: API Design Question

[James G Smith <JG...@TAMU.Edu>]

Shawn Devlin <sd...@recognia.com> wrote:
>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.

First thing to keep in mind is that CGI and mod_perl are two completely 
different environments.  It is true that Apache::Registry and co. help bridge 
the gap, but there are still things to watch out for even then.  A simple 
one-to-one correspondence in functionality between the two is difficult to 
make and probably will not yield an efficient implementation.

>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?

If it's an API, I'd not make one module per function, if by function you mean 
a call (e.g., fork() is a function in the Unix kernel API).  Instead, I'd 
group them by functionality (as in OS/2 - VIO, KBD, DOS, ...).  So one module 
might handle customer accounts, another handle news items, etc.

You probably want to analyse your application and do some redesign work at a 
basic level to take advantage of mod_perl.

>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.

This should be true.  Connections are maintained on a per-process basis and 
are global within that process.
-- 
James Smith <JG...@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Re: API Design Question

[Martin Redington <m....@ucl.ac.uk>]

On Friday, June 29, 2001, at 07:25 , Shawn Devlin wrote:

> What advantages do I gain by grouping the functions based on 
> functionality? As per my response to Mr. Worrall, one of my concerns 
> with placing each function call into its own module is the amount of 
> memory used by the various .pm files that will be loaded numerous 
> times. I can see that grouping functions based on functionality would 
> reduce the number of .pm files in memory. However, if I go that route, 
> then would I not be better just to leave the API as one file?

A good reason for grouping "related" functions is not so much 
"functionality" as common dependencies, and ease of change management.

If everything is in one huge module, then change management become 
tricky, especially with multiple developers. Giving every function its 
own module avoids this, but can make tracking down dependencies tricky 
(and there may be a small memory overhead for each module, but I've 
never looked).

A happy medium is to group together functions that share a dependencies 
on underlying database objects.

For example, if you have a family of library functions that retrieve, 
insert, update, or delete user records, it might make sense to group 
these together in a module. If you need to add a new field to your user 
records, then you change only that module (as well as any changes 
required to your scripts).

Re: API Design Question

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

James G Smith wrote:

[snip]

>>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?
>>
>
>If it's an API, I'd not make one module per function, if by function you mean 
>a call (e.g., fork() is a function in the Unix kernel API).  Instead, I'd 
>group them by functionality (as in OS/2 - VIO, KBD, DOS, ...).  So one module 
>might handle customer accounts, another handle news items, etc.
>
What advantages do I gain by grouping the functions based on 
functionality? As per my response to Mr. Worrall, one of my concerns 
with placing each function call into its own module is the amount of 
memory used by the various .pm files that will be loaded numerous times. 
I can see that grouping functions based on functionality would reduce 
the number of .pm files in memory. However, if I go that route, then 
would I not be better just to leave the API as one file?

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.