You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Matt Sergeant <ma...@sergeant.org> on 2001/05/16 22:53:22 UTC
Re: cvs commit: modperl-site index.html
On 17 May 2001, sbekman@apache.org wrote:
> + <li>
> +
> + <a href="http://template-toolkit.org/">The Template
> + Toolkit</a> is a fast, powerful and easily extensible
> + template processing system written in Perl. It is
> + ideally suited (but not limited) to the creation of
> + static and dynamic web content.
> +
> + </li>
I would venture to suggest that TT doesn't really fit into this
category. While it's cool and powerful, it requires more infrastructure
to get a website up than Pagekit and AxKit. I believe Andy has written
some sort of app server using TT though, so perhaps look into that.
Oh, and the section should be called "Application Servers", IMO.
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by Andy Wardley <ab...@cre.canon.co.uk>.
On Thu, May 17, 2001 at 04:34:38PM +0800, Stas Bekman wrote:
> > I would venture to suggest that TT doesn't really fit into this
> > category. While it's cool and powerful, it requires more infrastructure
> > to get a website up than Pagekit and AxKit. I believe Andy has written
> > some sort of app server using TT though, so perhaps look into that.
>
> Andy? what should we link to instead?
> (See the new item at http://perl.apache.org/#toolkits)
I think it fits into that category if you append something like:
The Apache::Template module provides an Apache/mod_perl
interface to the Template Toolkit, providing a quick and
simple way to integrate its processing power into your
web site.
I agree with what Matt is saying in principle in that the
Template Toolkit by itself is really just a tool, not a
complete framework. But once you add Apache::Template it
becomes possible to build a powerful page delivery framework
right out of the box.
But hey, I'm biased :-)
A
--
Andy Wardley <ab...@kfs.org> Signature regenerating. Please remain seated.
<ab...@cre.canon.co.uk> For a good time: http://www.kfs.org/~abw/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by "G.Richter" <ri...@ecos.de>.
>
> Sure, if you don't mind add a few words about these too:
>
> Mason
> OpenInteract (openiteract.org)
>
Ok, I writre something about Mason too and take a look at OpenInteract (but
I don't know much about it) in the next few days
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by Stas Bekman <st...@stason.org>.
On Thu, 17 May 2001, G.Richter wrote:
> >
> > anything else?
> >
>
> Embperl has become much more then embedding Perl into HTML over the last
> four years. So I would like to move it also down to the toolkit section. If
> nobody has any objection, I would write a few words and commit it to the
> modperl site
Sure, if you don't mind add a few words about these too:
Mason
OpenInteract (openiteract.org)
Thanks!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by "G.Richter" <ri...@ecos.de>.
>
> anything else?
>
Embperl has become much more then embedding Perl into HTML over the last
four years. So I would like to move it also down to the toolkit section. If
nobody has any objection, I would write a few words and commit it to the
modperl site
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by Stas Bekman <st...@stason.org>.
On Thu, 17 May 2001, Matt Sergeant wrote:
> On Thu, 17 May 2001, Stas Bekman wrote:
>
> > > > How about http://www.openinteract.org/ which is heavily based on TT.
> > >
> > > Yep, that should go in there too.
> >
> > anything else?
>
> Well you could add *lots* of modules in there, e.g. RAO, Apache-Template,
> Apache-OAS, Apache-iNcom, Zobel... You could/should probably add in Mason
> and EmbPerl there.
>
> But I think for that page you should just stick to modules that are
> actively under development, have an active community, and have a decent
> web page of their own to point to. I think that minimises it down to:
>
> EmbPerl
> Mason
> AxKit
> PageKit
> OpenInteract
OK
> and I guess ADT if it has a page and is well documented.
once we release the new version I'll add it too.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 17 May 2001, Stas Bekman wrote:
> > > How about http://www.openinteract.org/ which is heavily based on TT.
> >
> > Yep, that should go in there too.
>
> anything else?
Well you could add *lots* of modules in there, e.g. RAO, Apache-Template,
Apache-OAS, Apache-iNcom, Zobel... You could/should probably add in Mason
and EmbPerl there.
But I think for that page you should just stick to modules that are
actively under development, have an active community, and have a decent
web page of their own to point to. I think that minimises it down to:
EmbPerl
Mason
AxKit
PageKit
OpenInteract
and I guess ADT if it has a page and is well documented.
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by Stas Bekman <st...@stason.org>.
On Thu, 17 May 2001, Matt Sergeant wrote:
> On Thu, 17 May 2001, Stas Bekman wrote:
>
> > > Oh, and the section should be called "Application Servers", IMO.
> >
> > Do you suggest a new section or to rename the one I've created?
>
> Rename.
ok
> > How about http://www.openinteract.org/ which is heavily based on TT.
>
> Yep, that should go in there too.
anything else?
> > extropia.com will deliver their (our :) ADT with TT somewhere in June,
> > I'm rewritting it at this very moment.
>
> ADT? "Application Development Toolkit"?
Yes.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 17 May 2001, Stas Bekman wrote:
> > Oh, and the section should be called "Application Servers", IMO.
>
> Do you suggest a new section or to rename the one I've created?
Rename.
> How about http://www.openinteract.org/ which is heavily based on TT.
Yep, that should go in there too.
> extropia.com will deliver their (our :) ADT with TT somewhere in June,
> I'm rewritting it at this very moment.
ADT? "Application Development Toolkit"?
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by Stas Bekman <st...@stason.org>.
On Wed, 16 May 2001, Matt Sergeant wrote:
> On 17 May 2001, sbekman@apache.org wrote:
>
> > + <li>
> > +
> > + <a href="http://template-toolkit.org/">The Template
> > + Toolkit</a> is a fast, powerful and easily extensible
> > + template processing system written in Perl. It is
> > + ideally suited (but not limited) to the creation of
> > + static and dynamic web content.
> > +
> > + </li>
>
> I would venture to suggest that TT doesn't really fit into this
> category. While it's cool and powerful, it requires more infrastructure
> to get a website up than Pagekit and AxKit. I believe Andy has written
> some sort of app server using TT though, so perhaps look into that.
right,
> Oh, and the section should be called "Application Servers", IMO.
Do you suggest a new section or to rename the one I've created?
How about http://www.openinteract.org/ which is heavily based on TT.
extropia.com will deliver their (our :) ADT with TT somewhere in June,
I'm rewritting it at this very moment.
Basically we should start listing all the serious application servers and
toolkits on mod_perl site, to point people to the available things, rather
than hint to develop their own from scratch.
So what I suggest is that you guys throw in a few more items and then we
will see how to categorize them. What do you think?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 17 May 2001, brian moseley wrote:
> On Wed, 16 May 2001, Matt Sergeant wrote:
>
> > Oh, and the section should be called "Application
> > Servers", IMO.
>
> i think "application server" describes a system that does
> more than implementing a templating language.
Yes, that's the idea.
/me hopes you're not referring to AxKit :-)
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: application server
Posted by brian moseley <bc...@maz.org>.
On Mon, 21 May 2001, Brian Aker wrote:
> Nope, the opposite. A year or two ago I was at the perl
> conference and noticed sun passing out a marketing flier
> as to why you should write web apps in Java. They
> specifically defined servlet as a persistent component
> that could have a persistent connection to a database.
> They listed perl in the CGI category (which tagged it
> with all of the downfalls of a CGI).
in all the time i've been working with servlet engines and
applications, i've never once seen this definition. i'm not
saying you're lying, but i think maybe they got overeager in
crafting a message that would be appealing to you.
> Might as well use the definition where it is to your
> advantage.
it's mis-marketing. since i'm actually creating a perl
version of the servlet api, i respectfully ask you to
consider the appropriateness of the term before using it.
thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: application server
Posted by Brian Aker <br...@tangent.org>.
brian moseley wrote:
>
> On Sun, 20 May 2001, Brian Aker wrote:
>
> > FWIW I refer to any perl code that is persistent and is
> > making use of mod_perl as a servlet.
>
> "servlet" is a specific term coined by sun referring to a a
> specific component in the servlet api. you're just being
> uncreative and confusing.
Nope, the opposite. A year or two ago I was at the perl conference
and noticed sun passing out a marketing flier as to why you
should write web apps in Java. They specifically defined servlet
as a persistent component that could have a persistent connection
to a database. They listed perl in the CGI category (which
tagged it with all of the downfalls of a CGI).
Might as well use the definition where it is to your advantage.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: application server
Posted by brian moseley <bc...@maz.org>.
On Sun, 20 May 2001, Brian Aker wrote:
> FWIW I refer to any perl code that is persistent and is
> making use of mod_perl as a servlet.
"servlet" is a specific term coined by sun referring to a a
specific component in the servlet api. you're just being
uncreative and confusing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: application server
Posted by Brian Aker <br...@tangent.org>.
Gerald Richter wrote:
> I think "Application Server" is not a well defined term, so we may not get
> consensus here what it is. What's about calling the section "Application
> Servers/Toolkits running under mod_perl". Then it's up to the reader how
> he/she like to see it.
Its interesting to read this since I have always considered "Application
Server" to be a marketing term. I normally refer to slash (aka the
system
we use for slashdot and a few other hundred web sites) as an application
server.
FWIW I refer to any perl code that is persistent and is making use
of mod_perl as a servlet.
-Brian
--
_______________________________________________________
Brian Aker, brian@tangent.org
Slashdot Senior Developer
Seattle, Washington
http://tangent.org/~brian/
http://slashdot.org/
_______________________________________________________
You can't grep a dead tree.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: application server
Posted by Gerald Richter <ri...@ecos.de>.
>
> the end goal of a application server is to simplify the
> entire process of developing and deploying a complete
> application, not just one part of it. we're really talking
> about a whole different order of magnitude.
>
I agree to you with this goal (and that's what I done partly, for database
and sessions, in Embperl, what doesn't mean integration couldn't be
better...) also I don't believe we will see it soon. I don't like to decide
if Embperl (and the other modules) are Applikation Servers or not. That
depends on how you define the term. You define it in another way then Matt
does. That's why I suggest to call it "Applikaton Servers/Toolkits", because
it's more a toolkit to build an Application Server of the way you define it,
then a ready to run product.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: application server
Posted by brian moseley <bc...@maz.org>.
On Mon, 21 May 2001, Gerald Richter wrote:
> I agree to Matt, there is nothing missing for an
> application server, it's mainly a matter of installation
> and documentation, so for people not familar with CPAN
> it's maybe hard to find.
you're both missing my point. sure there are lots of
components on cpan. but most of them have apis that look
different, are documented in different ways, and are
configured in different ways. you have to install each one
and figure out each configuration syntax (some use named
parameters to object constructors, some use globals, some
depend on specific tools). many of these tools are dependent
on an apache environment.
here's an example. let's say i want to make an application
using mason for presentation and dbi to access a database.
somehow i have to construct and configure the mason parser
and interpreter. normally this is done either in a startup
script executed via PerlRequire or via mason-specific config
directives. also somehow i have to specify database info so
i can make a connection to the db server. there are a
billion different ways i could do this.
a true application server would provide an environment with
a single consistent configuration mechanism. application
deployers have one place to specify both mason and database
parameters using the same naming conventions, value types,
etc. application developers can use the exact same facility
for application-specific configuration, and they have a
single naming interface for accessing config data. the
specifics of configuring mason and dbi are handled by the
application server's glue. that's how the application server
claims to integrate configuration, presentation and database
access. furthermore, the configuration system isn't tied to
a particular deployment environment. it doesn't matter to
the application developer or deployer whether the
application is being run under mod_perl, speedycgi, or in
some other engine.
then add apis for logging and for managing sessions, apis
that are accessible to developers writing web applications.
make it so the deployer can simply twiddle a config value
and data goes to syslog instead of a file. again, not using
the apache mechanism, but an abstracted layer. notice that
the application deployer doesn't have to go get
Apache::Session from cpan and install it. the application
developer doesn't have to construct a
Apache::Session::Oracle with oracle or dbi specific
parameters, he just has to construct a
TheApplicationServer::Session, which uses that config api i
talked about earlier to figure out how to deal with
persistence.
then add an api for reporting data to a management system,
perhaps snmp, perhaps something else. again, deployers turn
a knob to figure that out. developers just use the api to
make data available. nothing specific to any particular
component. no building mod_snmp, reading its documentation,
or figuring out its configuration system.
the end goal of a application server is to simplify the
entire process of developing and deploying a complete
application, not just one part of it. we're really talking
about a whole different order of magnitude.
there's a whole huge class of people that don't want to
spend their time figuring out cpan and deciphering various
module author's foibles. they want to write code that adds
value to their business. they want infrastructure tools that
are as consistent, orderly and simple as possible. turnkey
solutions. plug and play, if you will. this is what the
application server is. "download a bunch of stuff from cpan"
is not an application server.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: application server
Posted by Gerald Richter <ri...@ecos.de>.
>
> The reason you need that though is Java *has* no CPAN. Want distributed
> objects, install CORBA::ORBit. Want database access, install DBI. Want
> auth*, go to Apache directory on CPAN and make your choice.
>
> IMHO, Apache *is* the unifying API for all of these things. And
> so I think we're fully justified in calling these things application
> servers.
>
I agree to Matt, there is nothing missing for an application server, it's
mainly a matter of installation and documentation, so for people not familar
with CPAN it's maybe hard to find.
I think "Application Server" is not a well defined term, so we may not get
consensus here what it is. What's about calling the section "Application
Servers/Toolkits running under mod_perl". Then it's up to the reader how
he/she like to see it.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: application server
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 17 May 2001, brian moseley wrote:
> On Thu, 17 May 2001, brian moseley wrote:
>
> > i think "application server" describes a system that
> > does more than implementing a templating language.
>
> er, that's not to diss anybody's software. everything on
> that short list is great stuff. but i stand behind my
> assertion. a (web) application server has more than
> presentation layer functionality. it is a complete
> application deployment environment. it's the same argument
> that matt makes for axkit not being a content management
> system but rather a building block for a cms. mason and
> axkit could be vital components of an application server,
> but it's false to label them as such themselves. i can't
> speak to embperl or the other things on the list, cos i'm
> not familiar with them.
>
> check out enhydra enterprise
> (http://enterprise.enhydra.org/). it has services for
> logging, naming, distributed objects, session management
> (through ejb), database access, transaction management,
> presentation (jsp), application control (servlets),
> management, authentication, authorization. all of these apis
> are immediately available to application developers and
> deployers in a consistent integrated fashion. this is not
> "download 18 different components from cpan and mash them
> all together" kind of setup. you can unjar the damn thing,
> run a config script, and it's ready to run apps. there are
> unified documentation and extensive sample applications.
The reason you need that though is Java *has* no CPAN. Want distributed
objects, install CORBA::ORBit. Want database access, install DBI. Want
auth*, go to Apache directory on CPAN and make your choice.
IMHO, Apache *is* the unifying API for all of these things. And
so I think we're fully justified in calling these things application
servers.
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
application server
Posted by brian moseley <bc...@maz.org>.
On Thu, 17 May 2001, brian moseley wrote:
> i think "application server" describes a system that
> does more than implementing a templating language.
er, that's not to diss anybody's software. everything on
that short list is great stuff. but i stand behind my
assertion. a (web) application server has more than
presentation layer functionality. it is a complete
application deployment environment. it's the same argument
that matt makes for axkit not being a content management
system but rather a building block for a cms. mason and
axkit could be vital components of an application server,
but it's false to label them as such themselves. i can't
speak to embperl or the other things on the list, cos i'm
not familiar with them.
check out enhydra enterprise
(http://enterprise.enhydra.org/). it has services for
logging, naming, distributed objects, session management
(through ejb), database access, transaction management,
presentation (jsp), application control (servlets),
management, authentication, authorization. all of these apis
are immediately available to application developers and
deployers in a consistent integrated fashion. this is not
"download 18 different components from cpan and mash them
all together" kind of setup. you can unjar the damn thing,
run a config script, and it's ready to run apps. there are
unified documentation and extensive sample applications.
the problem i'm interested in solving is how to provide
integrated components and consistent apis with this quantity
of functionality and level of sophistication in a perl
application server. i think it's still a long way away, but
it would be cool if i was proven wrong.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by brian moseley <bc...@maz.org>.
On Wed, 16 May 2001, Matt Sergeant wrote:
> Oh, and the section should be called "Application
> Servers", IMO.
i think "application server" describes a system that does
more than implementing a templating language.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-site index.html
Posted by Stas Bekman <st...@stason.org>.
On Wed, 16 May 2001, Matt Sergeant wrote:
> On 17 May 2001, sbekman@apache.org wrote:
>
> > + <li>
> > +
> > + <a href="http://template-toolkit.org/">The Template
> > + Toolkit</a> is a fast, powerful and easily extensible
> > + template processing system written in Perl. It is
> > + ideally suited (but not limited) to the creation of
> > + static and dynamic web content.
> > +
> > + </li>
>
> I would venture to suggest that TT doesn't really fit into this
> category. While it's cool and powerful, it requires more infrastructure
> to get a website up than Pagekit and AxKit. I believe Andy has written
> some sort of app server using TT though, so perhaps look into that.
Andy? what should we link to instead?
(See the new item at http://perl.apache.org/#toolkits)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org