http://www.portalux.com/applications/web/app-servs/

TWiki needs to sit alongside other apps

We can expect that the standalone paradigm to be less and less accepted: if the paradigm succeeds in getting the attention of executives, we can expect the mainstream collaboration tools will adopt the salient features that are making the wiki paradigm attractive, wikis grow into and threaten the territory of other collaboration tools or will need to leverage more complex services of centralised capabilities such as organisational workflow. At some point, standalone platforms will not cut it. Without some overarching coordinating mechanism, disparate projects will not converge coherently.

For any software platform, there is a growth limitation at which the limits of the design are reached and beyond which redesign or rearchitecture phase is needed to grow beyond. Every additional feature requires a mechanism through which to coordinate integration. If a integration strategy is not established controllably then integration costs, duplication and redudency will kill the project with complexity of noise that confuses and befuddles future development.

Standalone platforms are thus destined to reach a crunch point without a central integration mechanism to help drive interoperability or a phased platform development strategy through which emerging services can be recontextualised as services of the core. Without this refinement process the growth around the edges becomes complex and duplicated. Services in the core can be redundent or simplified cases of the emerging functionality. It is imperitive that the resulting intertwindness be simplified. Fail to do this and the project suffocates under the weight of the code and the attempts to support the old drain the developers.

Application Servers provide such a centrally coordination mechanism.

Perl:

• CgiApplicationFramework
  • There is CGI::Application::Framework, which implements clean OO way to do MVC (Model-View-Controller).
  • I was looking into it a little and it looks clean. They allow for different template engines, slightly prefering HTML::Template (because it does not have perl embedded - so you cannot sneak logic into template). There might be more qualified perl hackrs than me to add more
  • CGI::Application is a base for CGI::Wiki::Simple, I heard. -- PeterMasiar - 19 May 2003
  • CPAN:CGI::Application now has Twiki: http://twiki.med.yale.edu/twiki2/bin/view/CGIapp/WebHome (disclosure: I am the webmaster ). -- PeterMasiar - 13 Jul 2003
    • It seems from http://twiki.med.yale.edu/twiki2/bin/view/Kwiki/WebHome they were/are porting this to Kwiki
• POE: Perl Object Environment
  • POE is a toolkit for rapidly developing networking applications in Perl. POE’s powerful multitasking framework lets applications perform several tasks at once. POE’s message passing capabilities allow applications to be distributed across a network of machines
• Camalot (TemplateToolkit) - prealpha
  • Framework for building App Servers, not an app server itsself
    • http://www.template-toolkit.org/camelot/#sec_camelot_is_not
  • http://template-toolkit.org/tpc5/camelot/
• PAS - PerlApplicationServer - not changed since Jul 01
• SAWA - http://sourceforge.net/projects/sawa
• Mason http://www.masonhq.com/
  • Been around since July 1999
  • Has lots of modules - http://www.masonhq.com/code/contributed.html
  • Powers sites such as Avantgo
  • Features: (http://www.masonhq.com/about/features.html)
    • Simple embedded Perl syntax. Infuse your HTML pages with the full power of Perl: variables, arrays and data structures, conditionals, iteration, and the wide variety of freely available Perl modules.
    • Modular pages with components. Build pages from components that call one another and pass values back and forth like subroutines. Encapsulate common design elements (headers, footers, menus, logos) into shared components that need only change once to affect the whole site.
    • Parameter handling. Access GET/POST parameters directly as lexical ("my") variables. Assign default values or trigger error conditions when parameters are omitted.
    • Templates and filters. Assign a common template, filter, or piece of code to an entire site (or a particular section) with a single well-placed file.
    • Object-oriented techniques. Define your own methods and attributes on pages; access them from templates for increased flexibility.
    • Caching. Cache HTML and data, from small page elements to entire pages or complex data structures. Automatically expire elements after a certain time period or when a certain condition occurs.
    • Previewing. Using the built-in previewer application, review your page under a variety of client and request conditions: browser type, time of day, referer, etc. View a page trace with a breakdown of which component is responsible for each piece of HTML.

• • • Staging/production modes. Adjust configuration settings to maximize ease of development on a staging server and raw performance on a live server.

Python:

• Zope
  • Has the ability to host perl modules
  • Has functionality for WebDav, ftp interfaces
  • Hugely popular
  • Zope as a Platform: http://www.pault.com/pault/zope/zope.html

-- MartinCleaver - 09 Apr 2002, 13 Jun 2004