view release on metacpan or  search on metacpan

lib/App/faq.pod  view on Meta::CPAN

#!perl -w
# run this document through perl to check its syntax
use Pod::Checker;
podchecker(\*DATA);
__END__

=head1 NAME

App::faq - App-Context Frequently Asked Questions

=head1 INTRODUCTION

This is the FAQ for the
App-Context software framework
(a variant of the Perl 5 Enterprise Environment).
You can find out more background to the project on the web.

  http://www.officevision.com/pub/p5ee
  http://p5ee.perl.org

=head1 GENERAL

=head2 Why should I use App-Context rather than J2EE or .NET?

Perhaps it's because you prefer writing in Perl?
But besides that, there are other reasons.

Java's promise of "write once, run anywhere" is actually
better fulfilled by Perl than Java.

The .NET CLR's promise of "any language, one runtime
environment" is great.  But Parrot will do for dynamically
typed languages what the .NET CLR does for statically typed
languages.  (See http://www.parrotcode.org/faq/.)
And Perl6 will support the CLR as well.

I looked around at the state of various cross-platform application
runtime environments, and saw that the most pervasive execution 
environments, available across many platforms were: 
Perl (on servers), Java (on servers and browsers), 
and Javascript (on browsers).  Each of these technologies
holds the promise, to some varying degree, of
"write once, run anywhere". ".Net" was not yet on the scene,
but even when it arrived, the promise of proper cross-platform
support for .Net was a long way off and altogether uncertain.

Perl has excellent support even for unprivileged accounts
at ISP's, whereas Servlet support is hard to come by unless
you own the machine (or you go to a very specialized ISP).
Also, Perl offers several ways to do web applications: CGI for
unprivileged, quick and dirty implementations, and mod_perl
for high performance implementations when you have full control
over the web server (also PerlEx, FastCGI, etc.).

If you have a desire to program in Java and you like the API's
that Sun (and others) have created, you should probably focus
on Java. I think that things could be a lot simpler (or maybe
higher level) than the J2EE specifies them.

It seemed that the one thing that Perl was lacking was
a blueprint for large-scale development and deployment of 
high-performance, high-availability systems (i.e. enterprise 
systems) along with guides of discipline for coding and 
documentation.  The App-Context framework fills this gap.

So that's the explanation of "why App-Context?"

For an explanation of "why not App-Context?" you might consider that it
is still largely vaporware.

=head2 How well does the App-Context fit into a .NET technical strategy?

It may seem that App-Context is most at home with the following technologies.

  * Perl, Linux, Apache, CGI, and MySQL.