Re: Application framework namespaces
Lincoln A. Baxter wrote: 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? Sorry if I'm flogging a dead horse, but IMHO just pick a name, and make sure that you include a good introduction that weighs up the pros and cons of your module / system / framework versus all the others that you reviewed on your main POD file. Having LModule::Name style links in the intro will assist a person looking at the module to zip around the differing modules to perform a particular task. It was said before, but I'll repeat it - seperating out the logical components of the framework into seperate distributions (and perhaps releasing a Bundle:: to get the lot) would be well worthwhile. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Application framework namespaces
Michael A Nachbaur wrote: freshmeat.net works pretty well too This isn't a viable option for me. If this application is 100% perl, why go *outside* of the perl distribution network of choice to distribute it? freshmeat isn't a distribution network, it's an index of applications. We're rapidly careening off-topic here. -- [EMAIL PROTECTED] There's a fine line between participation and mockery -- Scott Adams
Re: Application framework namespaces
On Tue, 2004-05-18 at 12:37, Michael A Nachbaur wrote: This is the kind of problem I'd like to solve with a new top level namespace. Scripts are in a separate section of CPAN from modules http://cpan.org/scripts/index.html freshmeat.net works pretty well too -- david nicol People used to be able to read my thoughts, but it doesn't appear to work any more. Should I eat less cheese? -- Elizabeth Woods
Re: Application framework namespaces
On May 19, 2004 12:20 am, david nicol wrote: On Tue, 2004-05-18 at 12:37, Michael A Nachbaur wrote: This is the kind of problem I'd like to solve with a new top level namespace. Scripts are in a separate section of CPAN from modules http://cpan.org/scripts/index.html This isn't a script, its an entire application framework, built with over 50 perl modules. freshmeat.net works pretty well too This isn't a viable option for me. If this application is 100% perl, why go *outside* of the perl distribution network of choice to distribute it? -- Michael A. Nachbaur [EMAIL PROTECTED] http://nachbaur.com/pgpkey.asc
Re: Application framework namespaces
On May 18, 2004 11:25 am, Chris Josephes wrote: On Tue, 18 May 2004, Michael A Nachbaur wrote: Since the whole framework is 100% Perl, I feel it would be worth it to publish it on CPAN, especially since the underlying Perl modules can be extended by other users. This is the kind of problem I'd like to solve with a new top level namespace. The provisioning application sounds pretty cool, and it would probably get some feedback and use if it was published. Look over the custom modules you wrote and ask yourself the following for each one. 1. Does it stand alone on its own merits and provide a public function, or is it only really suitable when it's bundled with your application? 2. Will using an existing namespace in CPAN pollute that namespace with modules that don't work well without the entire framework of your application? Where possible I have used existing CPAN modules, like DateTime, Class::DBI, and so forth. The Perl modules in this application implement the business logic that ties all those other CPAN modules together. For instance, I have classes that inherit from Class::DBI to represent my database, SAWA classes that implement the application's event handlers, and so forth. I have already broken off bits of the application into stand-alone CPAN modules where appropriate (see AxKit::XSP::BasicSession, Class::DBI::Cacheable, etc) and continue to do so as necessary. Another thing to consider is does it need to be uploaded to CPAN in order to be public? Why not SourceForge, which is geared towards programming projects? Make one large tarball with the custom modules, include the other modules if necessary, or consider building a Bundle::(AppName) module to handle installing the rest. This one particular application is just one instance of a scenario where a Perl application can be distributed as 100% perl. CPAN is a wonderfully easy way to install modules, especially since dependancies can be automatically installed. Applications like AxKit or Apache::MP3 already reside on CPAN, but they have very specific functional areas they fit into. What I'm proposing is just continuing the same, except provide a dedicated namespace to applications themselves that can't fit reasonably anywhere else. -- Michael A. Nachbaur [EMAIL PROTECTED] http://nachbaur.com/pgpkey.asc
Re: Application framework namespaces
Lincoln A. Baxter wrote: Comments anyone? Lincoln What differentiates your framework from POE? -- [EMAIL PROTECTED] There's a fine line between participation and mockery -- Scott Adams
Re: Application framework namespaces
On May 17, 2004 02:04 am, khemir nadim wrote: I prefere technology sorted modules. The monster framework structures some distributions have, hide those nifty modules that you would like to use now and then. I also don't like to have simple modules part of a framework because more often than not they become very dependent on the framework architecture and since no one is going to refactor it, it's lost to the framework. snip I don't think that any other sorting than technological can work. In fact, next time Ill write some kind of framework I'd see that I (seriously) write the technology modules before I do any framework work. This isn't in the same realm as the sorts of modules I would like to deploy. I have several CPAN modules to my name, all of which are technology-named. (e.g. Class::DBI::Cacheable, AxKit::XSP::BasicSession, etc). However, those modules - as well as the one you describe above - are intended to be used by developers, not end-users. For instance, I've been toying with the idea of doing an AxKit-based webmail solution. So, it would use tons of CPAN modules under the covers: AxKit, Mail::Internet, Mail::XML, Net::IMAP, Net::LDAP, etc. However, the real magic is in how these CPAN modules are tied in together to make an application. Those Perl modules that define the application logic, event frameworks and XML output methods for creating a functioning application should have a place on CPAN as well. But, where does one draw the line? Mail? WWW? AxKit? It crosses many different disciplines and doesn't fit well in any one namespace. A more complicated example is the Intranet application I'm developing at work. It's a customer management system for a cable ISP, which has been under development for 2 years and is being open sourced. It uses uses a plethora of Perl modules and has tons of functionality, which includes bandwidth management, email account creation, website creation, cable modem provisioning, etc. It prints out PDF reports, uses barcode scanners to assign modems, and talks via SNMP to access our cable modem management equipment. To sum up, it uses over 50 CPAN modules, yet doesn't fit well in any category. Since the whole framework is 100% Perl, I feel it would be worth it to publish it on CPAN, especially since the underlying Perl modules can be extended by other users. This is the kind of problem I'd like to solve with a new top level namespace. -- Michael A. Nachbaur [EMAIL PROTECTED] http://nachbaur.com/pgpkey.asc
Re: Application framework namespaces
On Sun, May 16, 2004 at 02:17:12PM -0400, Lincoln A. Baxter wrote: 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. I'd be surprised if POE couldn't be made to play nicely with MQSeries. It's all kinds of flexible these days. POE doesn't rely on select() for its event dispatcher. It can use anything that multiplexes I/O and provides a timeout. The dispatcher interface is documented in POE::Loop, and the distribution already includes implementations for select(), IO::Poll, Event, Gtk, and Tk. It sounds like a low-level MQSeries event queue would be needed in addition to an event dispatcher. That's also possible. POE::Queue documents POE's generic event queue plugin interface. There is only one plugin so far, so the interface is still subject to change. What do you need? From my admittedly cursory readings on MQSeries, it sounds more appropriate for interprocess message passing than for low-level event queuing and dispatching. That is, a POE application might use its internal queue for local things and an MQSeries transport for passing messages to remote places. POE provides all the tools for interprocess message passing, but it doesn't enforce a standard method. At least one third-party transport, POE::Component::IKC, has been created to fill this void. Others are possible. Generally speaking, anything with an exposed filehandle can be plugged into a POE program using its low-level select_read() method. Even without an exposed filehandle, it is theoretically possible to wait for things in separate threads and inject incoming messages into POE's intraprocess queue. POE::Resource mixin classes can be created to manage these watchers and their threads, and POE::API mixins can expose the mechanics through friendly public interfaces. I say theoretically because these concepts are some of the newest introduced to POE, and their proofs haven't yet been implemented. They are desirable features, however, and POE developers would assist anyone wanting to add them. 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 As sensible as this is, I don't expect it to happen either. In fact, I would resist it. Revising, retesting, and redeploying POE based systems would cost thousands of man hours. A lot of people would be upset if they had to do it just for a name change. -- Rocco Caputo - http://poe.perl.org/
Re: Application framework namespaces
Lincoln A. Baxter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 Comments anyone? .. very long mail contents here Lincoln I prefere technology sorted modules. The monster framework structures some distributions have, hide those nifty modules that you would like to use now and then. I also don't like to have simple modules part of a framework because more often than not they become very dependent on the framework architecture and since no one is going to refactor it, it's lost to the framework. Let me give a little example, I have a build system (make like) written in perl. There's quite a lot that could be made generic and have more value than within the build system. I got tired of Data::Dumper output so I sprinkled code around to get the output I wanted. I did refactor it in a module (because I was forced to not because I was smart) that was left within the framework structure. Because the build system is not out on CPAN, I couldn't reuse the dumper module simply. Arghhh. So I finaly made a module that I can re-use as well as other perl devlopers (Data::TreeDumper, you'll like it or tell me why you don't). I don't think that any other sorting than technological can work. In fact, next time Ill write some kind of framework I'd see that I (seriously) write the technology modules before I do any framework work. Nadim.
Re: Application framework namespaces
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
Re: Application framework namespaces
On Fri, May 14, 2004 at 03:17:50PM -0400, _brian_d_foy wrote: In article [EMAIL PROTECTED], Michael A Nachbaur [EMAIL PROTECTED] wrote: The thing is, these are free-standing applications, and for the most part aren't developer tools. So, I was thinking an App:: namespace would work well, (e.g.. App::WWW::NachoMusic, etc). I'd rather see top-level namespaces for complete applications. I don't think the App::* adds any information. :) I would imagine that you meant to qualify this statement with an assumption that the applications have decently unique names, and not generic ones that might look like an existing standard use of a top-level domain (CGI, HTML, Data, WWW, etc). Mark
Re: Application framework namespaces
In article [EMAIL PROTECTED], Mark Stosberg [EMAIL PROTECTED] wrote: On Fri, May 14, 2004 at 03:17:50PM -0400, _brian_d_foy wrote: In article [EMAIL PROTECTED], Michael A Nachbaur [EMAIL PROTECTED] wrote: I'd rather see top-level namespaces for complete applications. I don't think the App::* adds any information. :) I would imagine that you meant to qualify this statement with an assumption that the applications have decently unique names, i didn't really care to do that, but you would have to anyway to escape the wrath of the PAUSE and CPAN admins. -- brian d foy, [EMAIL PROTECTED]
Application framework namespaces
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? -- Michael A. Nachbaur [EMAIL PROTECTED] http://nachbaur.com/pgpkey.asc
