Hi Ajit,
It's not entirely clear to me what problem you're trying to solve here.
I'll comment on some of the specifics you've written down here, but I
may be missing your larger point.
> OBJECTIVE
>
> Provide a perl server that can execute miscellaneous perl jobs that
> will communicate with mod_perl enabled Apache kids using IPC. This
> can be considered something similar to a master "Servlet" but in perl;
> call it Perlet. The master Perlet can manage a pool of kid Perlets that
> will be governed by the load.
You can do this fairly easily using RPC::PlServer or one of the other
RPC modules on CPAN. This is how DBI::Proxy works.
> MOTIVATIONS
>
> - Modperl in Apache 1.x does not provide a good way of sharing data
> and operations on that data in an efficient manner between Apache kids.
They may not perform quite as well as multi-threading, but there are a
number of modules that solve this problem pretty well. Apache::Session
is one example, and there are many shared cache modules out there.
Using the file system for this is a pretty good solution on systems that
do aggressive memory buffering of the file system, like Linux. (We were
just talking about this stuff on the Mason list. Seems like almost as
popular a topic as templating systems.)
One thing to keep in mind is that any perl server is likely to use a
multi-process approach and thus will have the same issues with data
sharing that mod_perl does. You'd have to get production quality
multi-threading support in Perl to avoid this, or write server that
multiplexes using select calls and non-blocking I/O.
> EXAMPLE USES
>
> The following are probably a bit ambitious. #2 and #3 are something that
> I can see implementing fairly easily. The most important thing would of
> course be the design of the API between mod_perl Apache and a Perlet.
>
> - Perlet::DB that will provide a pool of database connections and
> miscellaneous DB querying etc.
There's DBI::Proxy already. Before jumping on the "we need pooled
connections" bandwagon, you should read Jeffrey Baker's post on the
subject here:
http:[EMAIL PROTECTED]
> - Perlet::Mail that will provide asynchronous Mail handoffs
qmail-inject will cover this.
The other examples (HTML/XML parsers) don't make sense to me, since
these work fine with mod_perl and are generally synchronous
applications.
- Perrin
