I think the importance of splitting the core functionality into shared
objects is more general than that. There was some discussion a short time
ago about making a pared-down version for embedding, which would seem to
require some sort of functionality reduction. There is also the desire of
minimizing the footprint of the binary on heavily trafficked servers for
obvious reasons, and a shared object scenario would address this directly.
What I see as a typical installation would be similar to the means that
Apache uses, in which the administrator has the option of:
1.) Statically linking all required objects
2.) Loading required objects at run-time
3.) Loading required objects as needed by the source.
Item 3 is the most difficult to implement efficiently, but is not
impossible. Item 1 is not all that different from the existing
implementation, and Item 2, could be implemented using the Apache 1.3.x
model.
I'm not sure if it's possible with the last option, but it would be nice if
the binary could have both Perl compile-time/run-time, and execution-time
loading, allowing the core to have heavily used objects loaded at run-time,
and allow less used objects to be loaded as needed.
Another option might be to allow the core to be loaded as a daemon and the
SO's to be loaded as necessary by the core. This could allow the core to
spawn child processes to handle the individual tasks at-hand, and free the
core to be a simple 'traffic cop' (Just a thought).
Grant M.
[EMAIL PROTECTED]
