2000-09-11-16:23:20 Dan Sugalski:
> At 03:16 PM 9/11/00 -0500, Jarkko Hietaniemi wrote:
> >On Mon, Sep 11, 2000 at 01:12:44PM -0700, Russ Allbery wrote:
> > > INN has been embedding Perl for years, quite successfully.
> >
> >There's embedding and there's embedding. Embedding in an UNIX server
> >is different than from embedding in a RTOS microcontroller.
>
> Sure, but the original poster did bring up mod_perl as a failure of
> embedding, which pretty much assumes the first type of embedding.
I think the complaint about mod_perl's weight bears looking at,
despite the success of the INN embedding. One invocation of INN is
likely to do a sufficiently heroic amount of work that the weight
and bulk of a perl in there may well not hurt a bit.
A single httpd in something like apache isn't doing a whole heck of
a lot; to run a really high-volume server you want hundreds of the
things, and that gets out of hand terribly fast. mod_perls do not
help matters.
There's another embedding setting on Unix servers that has a similar
flavour (each invocation doesn't do a whole lot), and that's in a
simple filtering email Local Delivery Agent. perl-based filtering
programs don't blow procmail away because procmail weighs in at a
teensy fraction of perl's pork, so there's a radical difference in
sustainable email traffic levels.
I don't even want to embed the current perl in mutt; I'd love to
have a scripting and extension language embedded in there, but not
one that's bigger than all the rest of the application.
The exact same design targets --- really really fast, teensy memory
footprint --- that define the microcontroller embedded market, also
define the entry to these roles on the biggest servers.
-Bennett
PGP signature
