Adam Worrall wrote:
>>>>>>"SD" == Shawn Devlin <[EMAIL PROTECTED]> 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
