On Tue, 2004-05-11 at 14:29, Michael A Nachbaur wrote:
I'm working on a web application that is almost 100% perl (the styling is
handled in XSL). The entire application's test and installation procedure is
managed with a Makefile.PL, and the entire package is very CPAN-ish. I
wanted to know if there was some place on CPAN that I can publish it so other
people can deploy my application if they choose?
I'm using the namespace Nacho::AppName for my modules (Nacho being my IRC
nick), but if there was an App::Foo namespace that could be used, I'd be
willing to upload this to CPAN when I'm finished.
Does anyone see having this sort of code in CPAN as being useful?
I have been work on this for several months... this makes time to say
something: This email, made be realize that it might be worth getting
our ideas (on a top level namespace) on the table.
This is a long email. It is long because I need to describe what we have
in order to setup some context for the discussion.
We (I and a team off 4 other folks) have implemented -- over a period
of 3 years -- a commericial grade perl server suite which is providing
application integration services today for a number of customer
facing applications at a major financial services company.
Several of us are now doing a clean rewrite of this independent of our
employer) with the intention making it available on CPAN. This is a
suite of object oriented modules which implements a Generic Application
Integration Framework or Platform. (Here after referred to (in this
email) as Framwork.
Our Framework allows for the implementation of perl servers and scripts
that can manage file, socket, MQSeries, or even email or database based
interfaces in polymorphic way, and have standard error handling, logging,
event notification, and configuration. This Framework will support the
following:
- Easy Extensibility
- Easy Configuration (internal and by various file formats)
- YAML
- Perl Hash Ref
- XML
- Dot notated hierarchy
- ini file
- Consistent easy to use Exception handling
- Separable components usable in standalone scripts
- Polymorphism between request interface types:
- MQSeries
- sockets
- files
- Databases
- Multiple Message Formats
- request and response can be in different formats
- XML (various flavors)
- tag value
- CSV
- Fixed Format
- Server templates
- single client/multiple clients
- singleton/forked/threaded
- managed
- Apache integration
- FastCGI
- mod_perl
- Cron harness
- Object persistence/caching, maintaining client session state
- Inter-process communication
- Unix domain sockets
- fifo
- file ipc
- db ipc
- semaphores
- Clear Distinction between notification of events and logging
- Polymorphic event notification between various monitoring systems:
- Openview
- Syslog
- Tivoli
- BMC
- Logging various loggers can be configured:
- Log4Perl
- stdout
- file
- Regression test environment for testing server specific functionality
In thinking about this repackaging we have done a review of the Modules
List and searched CPAN, looking for an appropriate TLNS into which our
suite/framework might fit.
We found many 'Server' packages buried in namespaces dedicated to specific
technologies, techniques, and environments. Examples include:
VoiceXML::Server
NNML::Server
Net::Server
NetServer::Generic
VBTK::Server
SOAP::Transport::HTTP::Server
RPC::XML::Server
Apache::RPC::Server
Net::SMTP::Server
Net::SNPP::Server
Net::TCP::Server
etc...
Our Frame work is more generic than any of these, and does not fit in any of
these names spaces. And then there is:
POE
Wombat
POEST
NetServer
Event
etc
Lets talk about POE. With POE we have a suite of packages whose scope
and breath is not unlike what we have put together with GIP.
Infact when we started originially, we looked at POE. At that point
we considered it not quite what we were looking for. On reviewing it
again recently, we find it's now got GREAT documentation, an impressive
following, and much more maturity, but its still not suitable for some
of the things we have been doing. For instance, core to the POE module
at least for implementing servers is the interfaces must support unix
select(). We needed MQSeries.
Our Framework can be used to solve many the same kinds of problems
that POE solves, but it is more generic in its use of interfaces.
POE services assume that request interfaces implement IP socket
semantics, supporting the use for the unix select() function.
Our Framework can be used to implement servers whose request interfaces
include propriety transports like MQSeries or Databases. Infact, MQSeries
is what most of our current production servers use. Our
