Shawn,
We have taken the approach here of a format like the on laid out below:
(in startup.pl - use lib '/usr/local/apache/lib'; - add the directories to
@INC)
/usr/local/apache/lib/APP - where APP is the main name of our application.
In this directory we will have perl modules that are shared by all the
handlers that make up the application.
Inside this directory we have a directory for our handlers - the handler
would relate to the 'command=foo' part of your current call - like:
/usr/local/apache/lib/APP/Command
Inside the directory for the handler we have at least a Handler.pm which is
reference in out perl.conf something (well exactly like):
<Location /command>
SetHandler perl-script
PerlHandler APP::Command::Handler
</Location>
Inside the Handler.pm perl module is a sub called handler that processed the
requests made to that command. We also have a perl module for each action
related to a command, like:
List.pm - to process things related to a /command?action=list call.
For out situation, this works well because it allows several developers to
work on different parts of the same Command without stepping on each others
toes, so to speak. Of course, this does add a level of complexity to
project, that in the beginning was met with some resistance by long time
perl programmers - myself included and I thought of the layout, but in
practice it has let our team cut development times significantly. Of course
a good versioning system will allow multiple users to access the same file
and not cause problems, and we use CVS to provide version control.
As with anything, you milage may vary with this method. I'm sure there are
hidden pitfalls involved with this method, but for the timebeing it does
seem to work for us. I hope this helps.
Good Luck
Joe Breeden
> -----Original Message-----
> From: Shawn Devlin [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 29, 2001 1:18 PM
> To: [EMAIL PROTECTED]
> Subject: Re: API Design Question
>
>
> 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
>
>
