I like Ajit's recommendation, the RFC (along with a framework like
Stephan's) to allow some brainstorming.
I guess I feel quite odd. I posted some stuff yesterday or the day before
on the mod_perl list about Perrin's article and then I go to sleep after
subscribing to p5ee and then wake up to find like 50 messages in my in-box.
One of these days I need to move back to the other side of the world in the
USA to keep up with the conversations. :)
Anyway, I've found that there are too many messages to respond to
individually (I would blast the list with 15 messages) so I guess I'll
respond in one big post.
==
1) Although I think some of us disagree on some things, I see some semantic
differences of opinion that I hope we take them for what they are -- just
semantic rather than philosophical. And I promise to try to not fall into
that trap myself.
When using buzzwords, it's quite easy for people to come up with different
ones to describe the same thing. :)
2) I see a lot of talking about APIs. I believe that the best thing is to
reuse what is on CPAN and at most (taking from Robin's message -- my first
direct reply!!) a P5EE::xxx wrapper api.
Those that think otherwise should sit back and ask themselves -- "Would I
have time to implement it?" because if you don't, then chances are few
other people will either. So laziness is a virtue.
I like the idea of a P5EE::xxx API but feel that it would be better
reserved for Phase "2" of the P5EE initiative (My 2nd direct reply thanks
Greg for your Buffy quote) as I believe the first complete phase is
documenting what exists.
3) Greg McCarroll had many of the first comments I saw pretty well laid
out. I hope he accepts that I am not going to requote much of his post, but
I will try to address some specific things that stood out whilst I was
taking notes:
* That p5ee should not be 100MB tarball. I agree. I think bundles would be
much better but optional bundles. It's quite possible someone could grab
the p5ee bundle, but just as well that they might just grab a subset of
p5ee in a separate bundle.
* Not replicate j2ee. Again I agree, although I believe j2ee has many
lessons to learn from. Same for .Net (well really no lessons to learn from
other than not to charge developers US$1000 to join).
* Buzzwords in j2ee making developers feel happy. I disagree with this.
Greg I apologize if this comes across harsh, it may be a semantic
difference that I am disagreeing with and hope you and others don't take it
that way.
I know I did not start the p5ee initiative, but I certainly struck a small
cord by posting on mod_perl 2 days ago that I "feel" that j2ee was better
for some of these enterprise things and I "feel" better doing them in Java.
I have been programming in Perl and Java for a while and feel I choose the
easiest tool for the Job. In my case, I actually do in some cases believe
Java is easier and has less hurdles. One of those hurdles is documentation
and standardization when it comes to enterprise level APIs as well as
finding programmers that know those APIs to help me on the project.
It's not really about buzzwords. I don't believe you really think that so
many Java programmers in the world are only using Java because of
buzzwords. There is actually real code and real benefit in Java.
I think j2ee has real promise and real benefits. I truly believe Sun has a
good thing going for it. I also believe Perl has a good thing going for it,
but for "enterprise programming" it does lack documentation,
standardization, test cases, and programmers who do "enterprise"
programming and this is a very real weakness. It doesn't make Perl a weak
language any more than it makes Java a stronger language -- just that they
may be used in different situations.
4) Ajit - Had talked about an RFC process. I believe this is correct. P5EE
has been talking about by many people before... I think I recall it even
being mentioned at ApacheCon London.
But the bottom line is that different people have different things they
want to achieve out of P5EE and so it's important to brain storm for a few
days to see what comes out.
Then solidify that brainstorming (Stephan's webpage is one such attempt)
and provide structure to further RFCing.
Of course, a formal RFC would actually have structure from the start, :)...
But I think we are getting there especially with the constructive listing
of APIs that Paul Kulchenko, Chris Winters, Walt Knowles. John
Napiorkowski, and others have done last night (I hate all of you for your
long emails posted at night causing me to read this this morning and be
late for work! :))
5) Nat -- Said some good things but a couple I want to address.
First, do I feel the need for J2EE style beans? Well, I wasn't going to
respond but I saw some negative posts on beans in response so I feel
compelled to respond to those responses.
So I will say that I would see some benefit out of beans in Perl. There are
two things that are nice about beans. One, beans specify a common get/set
method API allowing introspection to determine properties of the object.
Two, bean state can be serialized so both the code and the state are
serialized side by side. To say that someone doesn't think beans are
important -- well, on the surface they aren't .. but they are important in
the sense that they are objects with serialized state and a common API for
exposing properties.
At minimum this is useful for creating an IDE that needs to know the state
of a given object so that the IDE can get and set the properties for you
and then "deploy" that bean inside the container. Otherwise how is the IDE
or other toolkit going to know how to tell you what the properties of the
object are? In Perl there's not even a syntax to say some methods are
public versus private nor to tell the difference between a cosntructor and
normal method! It sure would be nice if there was a true convention that
would make Perl "beans".
HOWEVER -- I do not necessarily believe that Perl beans are necessary for
P5EE initiative. I just wanted to explain to some of the naysayers that
beans are useful.
Second,
Java being no brainer for email, transaction, persistence.... I don't know
if I agree with all that. email is moderately easy but the interface is
basically SMTP and that's it. The transaction API is pretty good, but the
world of persistence is fairly fragmented in Java.
I think messaging was also mentioned. Of course, messaging is still new in
Java and I know very few people who have used a messaging server in Java at
all.
So what makes these things get "perceived" to be no brainers? I would guess
it's the documentation. A thread which I'll follow on later.
6) Chris Winters --
Hey, can someone please remember to include JAAS that he suggested earlier
yesterday. Java Authentication and Authorization Service. It is very
comprehensive and quite a useful API especially for services.
I think Paul's list is the most comprehensive, so whomever is writing this
down (assuming it's Stephan), please add JAAS. Just saying
"Authentication/Identification" isn't as comprehensively covered
I also really like Walt Knowles Introspection and Personalization API. The
Introspection API is really very similar to the notion of having Perl
"beans" as introspection is already part of the Perl language.
Personalization is also quite a useful API -- I am not sure it even exists
as a standard in Java yet.
7) OK, now to end with my own comments... they may not be original, but I
don't think they were said quite this way.
a) I believe that we may become too overzealous in P5EE initiative. I see
many topics being thrown about from the concept of just beans and
exceptions all the way to object persistence frameworks.
I believe that we need to categorize these things lest we try too much. It
is POSSIBLE that some of the things would be useful to PUSH in general as a
PERL initiative to support P5EE, but I don't think it should all be P5EE.
I view these categories as
Core Language Features
P5EE Features
Application Features
Core Language Features are Perl Bean standard, Exception and Error handling
standards, Logging, Diagnostics, etc. These should all be normal CPAN
modules. They shouldn't be considered part of an enterprise initiative as
they are just features that would be useful to build on for an "Enterprise"
Perl application but other "Non-enterprise" applications should be allowed
to benefit.
Application Features are features that are too fragmented and have too many
ways to skin the cat that they should be references as part of P5EE and
supporting P5EE, but should not be part of P5EE specifically. For example,
Database Persistence and OO->DB mappings are not P5EE. Same with Web
Application toolkits like eXtropia toolkit or OpenInteract. They may
support P5EE, but again, should not be P5EE. These are individual
implementations at a higher application level.
P5EE Features are core APIs that do specific things and where there is
going to be very little resistance or hard feelings (comparatively) if one
is chosen over the other because it will be quite obvious what a good API
is and what a bad API is.
This also brings us to the nature of Perl, Perl is a community effort not a
dictatorship. Standards are great to have, but it many cases it is too late
and actually it's conceivable that we do not wish to stifle the creativity
in terms of application server frameworks and template languages and the
like. The best way is to keep P5EE focused on the core things.
b) Robin is correct about documentation. Well, this is kind of a reply I
guess (but I did promise I wasn;t necessarily going to be original)...
I believe Documentation is the total key to P5EE. After focusing on all the
APIs (which are good to inventory for the RFC anyway), we should map them
to CPAN, see what the reality is and then document them.
Basically this would be the guide to Enterprise Perl. Just as Stas has a
guide to Mod_perl and teaching people how to put together mod_perl apps,
this list should ultimately have an Enterprise Perl guide....
"I have an enterprise problem X how do I solve it"... "Go view the guide!"
would be a lovely response that we see over and over again on the mod_perl
list. I truly believe that Perl already has many good frameworks. It's just
a matter of figuring out what is useful for which "Enterprise" purposes and
then bringing the user's to those APIs.
They just aren't really well documented.
This is why I view P5EE as a multistep process with the following milestones...
1) Identify Enterprise APIs (Brainstorm)
2) RFC Them
3) Map them to current modules
4) Document them as one whole helper document about how to find a solution
to X enterprise problem (following the API list basically)
5) Identify Applications and Frameworks that use the modules identified in
3 and label them as P5EE Enabled. These frameworks would explicitly be
documented in case people want to see these APIs in use.
6) Then take a step back, look at the APIs and identify which ones would
benefit from standardization (mail is one)
7) Standardize it
8) Redocument
9) Rinse, Repeat.... #6
6-9 will take a long time ... possibly forever. So don't hold your
breath.... but it will come slowly.
10) In parallel for 6-9, should be initiatives where people say "wouldn't
it be cool to do X for the p5ee initiatve" and they will do it. eg JAAS or
a personalization API comes to mind.
11) Document
12) Rinse, Repeat #10.
Concretely,
This whole thing is a long process. But doing enterprise "meta"
documentation need not be. Ideally it would be someone like a Stas Bekman
but someone who believes in Enterprise Perl and who can take on a similar
banner of work that Stas did for the mod_perl guide.
Then more sophisticated documentation and APIs can come out of the
community that forms on this list. At that point I would see this list
splitting into TWO lists. [EMAIL PROTECTED] and [EMAIL PROTECTED]
The discussion we are having now would go on [EMAIL PROTECTED] in
the future, and [EMAIL PROTECTED] would be the defacto standard place where new
developers can come and ask questions like "I need to hook up to my Java
SOAP Server from Perl, how do I do that?"
Well, it's time for me to go to sleep again, and wake up to see another 40
p5ee mails in my inbox. :) Don't yell at me too harshly please. I am just a
person who happens to program Java but also likes Perl. Sorry if I believe
in the buzzwords...
Later,
Gunther
PS Also please add NAMING to the list of P5EE interesting APIs... As in
JNDI (Java Naming and Directory Interface)... Naming is distinctly
different from a directory and is an important highly useful part of the
Java API. I love using naming.
What is it? It's so simple it's almost stupid. It's a way of asking a
standard naming API "Give me object X" and then it will look up "X" and
then create it or give you the object if it already exists... The backend
can be anything from SOAP, LDAP, JDBC Connection Pool, RMI etc... Just
about every Servlet Container comes with a JDBC connection pool where you
set up a JDBC connection and then "NAME IT". Then to get the JDBC
connection, you just use the naming interface to get the "addressbook" JDBC
connection.
Anyway, just want to make sure naming service doesn't get forgotten since
directory service tends to just refer to a single interface to something
like LDAP.
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
