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 framework is
so generic in its use of interfaces (they must only support open(),
close(), read() and write()), that we could build a Mail interface that
uses SMTP/POP3 as a transport layer and it could be used polymorphically
with any of our other interface formats (file, socket, or MQSeries).
Given that there are already several of TLNS server frameworks, we have
been debating whether we should just created a new one, or whether
it would make sense to create a TLNS, in which all Frameworks could
(logically at least) reside. We would like to through this out to the
Module Authors for discussion.
Creating a new TLNS dedicated to our Framework say: AIF (Application
Integration Framework), would be a continuation of past practice. But,
perhaps it would be better for the "marketing" of all Frameworks,
we a TLNS into which all such Frameworks could eventually be placed.
Framework:: comes to mind.
We like Framework:: because all of our components will be usable to create
servers, or to build other types of scripts. With Framework:: one could
have any number of Server or Application platforms or frameworks. For instance:
Framework::AIF (our Application Integration Framework)
or perhaps:
Framework::AIP (Application Integration Platform -- since Framework would
already be in the Namespace)
and of course:
Framework::Nacho (or what ever name Michael picks).
If Michaels App(s) are not really Frameworks, then how about Application::
for his app(s).
Logically atleast, existing Framesworks _could_ be migrated to
Framework:: as well (although I don't really expect that to happen).
Framework::POE (currently POE::)
Framework::Wombat:: (currently Wombat::)
Framework::POEST:: (currently POEST::)
Framework::NetServer:: (currently NetServer::)
etc
Does it make sense to create a new generic TLNS into which one might
hope to eventually see all such Frameworks migrated, or, should we just
go for our own new TLNS?
Perhaps given some of the recent discussions about the fact that
search.cpan.org has made the Modules List somewhat unnecessary we
should just not worry about it.
Comments anyone?
Lincoln
