Wild Proposal :)

[Ajit Deshpande <aj...@skycorp.net>]

The following is a half-baked proposal for a wild idea. Please comment on
this. If the powers that be think this is OT, then please move this I
will take it elsewhere.

If this is something that is already implemented by 'Application Foo' or
'System Bar' then please let me know and you will hear no more :)

Ajit

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.

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.

- We often want to execute perl jobs in Apache kids but do not want to
  incur the expense of forking a perl interpreter.

- Trying to stuff everything into packages and loading in the parent
  Apache has limitations.

IMPLEMENTATION

I have no idea :). I am an intermediate perl programmer, but can take a
stab at this after getting some feedback on this RFC.

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.

- Perlet::Mail that will provide asynchronous Mail handoffs

- Perlet::Data that will provide some in-memory datastore that can
  be used for looking up codes etc. Example: list of 50 states in the US
  used to populate SELECT forms in html page. list of countries.
  Anonymous hash references and subs on that data to return specific
  values. Example: numerical IDs corresponding to a SELECT list. 

- Perlet::Java::Servlet : Mechanism to communicate with Java Servlets

- Perlet::XML::Parser : XML Parser 

- Perlet::HTML::Parser : HTML Parser

- Perlet::CyberCash : Communicate with the Cybercash server

Re: Wild Proposal :)

[Perrin Harkins <pe...@primenet.com>]

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://forum.swarthmore.edu/epigone/modperl/breetalwox/38B4DB3F.612476CE@acm.org

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

Re: Wild Proposal :)

["Marinos J. Yannikos" <mj...@geizhals.at>]

> OBJECTIVE [...]

Interesting idea, I'm sure that many others have at least thought once or
twice about the benefits of such a system. I would find it very useful.

> - Perlet::Java::Servlet : Mechanism to communicate with Java Servlets

There is an Apache::Servlet module, which apparently hasn't been updated
recently. I'd be very interested in mod_perl -> servlet communication, esp.
a way of including Servlet/JSP output in a mod_perl script (without having
to use HTTP). Any takers for an Apache::Resin module?

Regards,
 Marinos
--
Marinos J. Yannikos
Preisvergleich Internet Services AG, Linke Wienzeile 4/2/5, A-1060 Wien
Tel/Fax: (+431) 5811609-52/-55