how many of you read the article linked by slashdot today,
entitled 'a perl hacker in the land of python', at
<http://www.byte.com/feature/BYT20000201S0001>?
the last point, that the perl world has no application to
compare to zope, is 100% dead on. im not so concerned with
perl having a 'killer app' to lead newbies to the language,
as i am that if i want to write a web application that i
want to be widely used, i have to choose from a number of
different architectures: mason, embperl, eperl, asp,all of
the other happy template-based systems, cgi emulation
(Apache::Registry), roll my own, etc. its really frustrating
that a large part of the user community has to miss out on
my application because their sysadmin doesnt want to install
mod_perl, or is religious about mason, or whatever.
besides python/zope, look at java's j2ee. even better: you
have a well defined web server interface (the servlet api),
a well defined application server environment (ejb), and a
well-embraced user interface mechanism (jsp). not everybody
loves every piece of j2ee, but there is significantly less
fragmentation in that world than in ours. in fact, even if
you choose to not use jsp for your user interface, you can
still take advantage of all of the features provided by a
servlet container, as guaranteed by its conformance to the
servlet spec. so if your application also conforms to the
spec, then sysadmins all over the world can configure and
run it in exactly the same way they run every other servlet
application. no setting up /perl for Apache::Registry,
/mason for mason, matching *.ehtml with embperl, trying to
figure out how to construct different mason interpreters for
two logically separate applications with different security
requirements. it all just works (well reality may be a
little different but 80% of the way there is much better
than 10% of the way there).
i've been tossing around the idea with a few other folks of
a perl port of cocoon (<http://xml.apache.org/cocoon>). one
of the reasons we cant build an almost lookalike version is
that we have no standard web server interface, so we have to
tie ourselves very closely to the apache api. this means
that folks with investments in netscape and microsoft
servers and dependent technologies dont get to use our work.
suck. so i've been thinking about the feasability of porting
the servlet api itself. this addresses part of the problem,
but not the 'application framework' part that so many people
love to re-invent: how do i efficiently manage connections
to backend resources (databases, directories, etc)? how do i
implement transaction management, event notification,
messaging services, etc? again, in the java world, people
are tending to use ejbs and container managed persistence in
combination with jdbc, jndi, jms, javamail, etc. standard
apis that every application writer can assume.
in a slightly different vein - somebody said to me once:
'where do you we make dollars? email messages and calendar
events, or threads and databases?' if we want perl to
continue to be taken seriously as a choice for business and
consumer applications, we need to make it easy for
professional application developers to concentrate on the
activities that more directly help them generate
revenue. tmtowtdi is great for building components, but it
can be terribly frustrating for user apps.
entitled 'a perl hacker in the land of python', at
<http://www.byte.com/feature/BYT20000201S0001>?
the last point, that the perl world has no application to
compare to zope, is 100% dead on. im not so concerned with
perl having a 'killer app' to lead newbies to the language,
as i am that if i want to write a web application that i
want to be widely used, i have to choose from a number of
different architectures: mason, embperl, eperl, asp,all of
the other happy template-based systems, cgi emulation
(Apache::Registry), roll my own, etc. its really frustrating
that a large part of the user community has to miss out on
my application because their sysadmin doesnt want to install
mod_perl, or is religious about mason, or whatever.
besides python/zope, look at java's j2ee. even better: you
have a well defined web server interface (the servlet api),
a well defined application server environment (ejb), and a
well-embraced user interface mechanism (jsp). not everybody
loves every piece of j2ee, but there is significantly less
fragmentation in that world than in ours. in fact, even if
you choose to not use jsp for your user interface, you can
still take advantage of all of the features provided by a
servlet container, as guaranteed by its conformance to the
servlet spec. so if your application also conforms to the
spec, then sysadmins all over the world can configure and
run it in exactly the same way they run every other servlet
application. no setting up /perl for Apache::Registry,
/mason for mason, matching *.ehtml with embperl, trying to
figure out how to construct different mason interpreters for
two logically separate applications with different security
requirements. it all just works (well reality may be a
little different but 80% of the way there is much better
than 10% of the way there).
i've been tossing around the idea with a few other folks of
a perl port of cocoon (<http://xml.apache.org/cocoon>). one
of the reasons we cant build an almost lookalike version is
that we have no standard web server interface, so we have to
tie ourselves very closely to the apache api. this means
that folks with investments in netscape and microsoft
servers and dependent technologies dont get to use our work.
suck. so i've been thinking about the feasability of porting
the servlet api itself. this addresses part of the problem,
but not the 'application framework' part that so many people
love to re-invent: how do i efficiently manage connections
to backend resources (databases, directories, etc)? how do i
implement transaction management, event notification,
messaging services, etc? again, in the java world, people
are tending to use ejbs and container managed persistence in
combination with jdbc, jndi, jms, javamail, etc. standard
apis that every application writer can assume.
in a slightly different vein - somebody said to me once:
'where do you we make dollars? email messages and calendar
events, or threads and databases?' if we want perl to
continue to be taken seriously as a choice for business and
consumer applications, we need to make it easy for
professional application developers to concentrate on the
activities that more directly help them generate
revenue. tmtowtdi is great for building components, but it
can be terribly frustrating for user apps.