At 11:11 PM 10/25/2001, Greg McCarroll wrote: >* Gunther Birznieks ([EMAIL PROTECTED]) wrote: > > > > When using buzzwords, it's quite easy for people to come up with different > > ones to describe the same thing. :) > >If someone has copious free time, they could create a glossary for >this initiative, that way when we use a term onlist we hopefully all >mean the same thing. This may seem overkill but I do believe that >terms such as "Perl Beans", services, components, frameworks, etc. are >all fairly ambiguous at the moment.
I think this is reasonable. I don't really have the free time but I've responded to this by posting a sample glossary for these and other common terms I've seen bandied about this list. > > 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 may or may not be disagreeing here with you, but I like the idea of >a standard API for each aspect of P5EE. I think that while existing >modules can influence the design of the API, in the cases where their >is one full implementation of an aspect, it should still be open to >debate in order to increase generalisation. An example might help ... > >if we decided we need a Local Storage standard, then we shall probably >create P5EE::Storage::Local , now it may well be that we almost always >use DBI to implement this, i.e. P5EE::Storage::Local::DBI > >now i wouldn't want to see P::S::Local being an exact copy of the DBI >interface, because someone may come up with a better local storage >option at some stage, and i'd rather not see them have to jump through >hoops to get their system to comform to the standard P::S::Local >standard > >of course, i am a great believer in theoretical arguments such as this >being made null and void by someone "Just doing it" (thats the >clearner version of the phrase) That can be true. But I also know how long such API discussions will take. Once an API reaches a "standard" form, then people become much more heated about it than when it's just one person's interpretation of what the API should be without the baggage of being labeled a "standard". > > 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. > >if we as a group end up in disagreement in this, we shall simply split >into two factions and attack the problem in a pincer movement Well, that's not necessarily bad. But I think the documentation is still the most important thing. To document what exists now so that people wondering how to solve common enterprise problems know which parts of CPAN are recommended for those problems and how they possibly fit together. > > 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. > >I think this is a fair assesment of things and for those of us who >want to see Perl being more dominant in the ``Enterprise'' market, it >sets out a challenge (however also remember richard dice's point that >we also need to make sure perl is good as "enterprise glue") That is quite possible. Perl made a lot of it's name being a glue language (a theme consistent with Lincoln Stein's seminal "How Perl Saved The Human Genome Project" article: http://www.ddj.com/articles/1997/9718/9718e/9718e.htm This was back in the day where computer systems were really separate programs in the same process space that typically dealt with piped data and/or required quickie programs. Java sucked for such things. I see two things that have changed this. 1) For global or infrastructurally geographically dispersed enterprises, single process space glue doesn't cut it. Everything is linked by networks and 2) XML is now considered the "glue language". Java talks XML fairly well and also talks over the network fairly well. This would make it compete head to head with Perl. Then there are two features now that Java has over Perl for being enterprise glue. 1) for writing a shared memory network server, Java's built in threading makes such things really trivial and 2) Java has standardized enterprise APIs. I think if Nat said a couple years ago that this was not important, he was likely correct. Then. But just as Microsoft is potentially set to lose the desktop war as systems become more distributed, language-centric wars are likely going to be lost to languages that make gluing networks together easier than they are now. My belief is that Java makes network programming easier at the moment, and that Java progammers are more familiar with how to program network servers than Perl programmers in general due to the education that Sun has promoted quite heavily. So now there's a bit of catch up to be done, but we shouldn't necessarily do a 1-1 catch up with J2EE, I think p5ee should emphasize the advantages of Perl because Perl is a different language from Java. I don't think it can compete with identical APIs for everything when the languages are different and stuff designed for Java may not work so well in Perl. I think a large part of what makes these things hard in Perl is not that we lack frameworks but that we lack a central place where someone can look up how to do this enterprise glue stuff in Perl with examples. Of course, this is what the P5EE list is going to help solve. :) And this is why I believe the initial documentation would benefit from being similar to the mod_perl guide by Stas Bekman. The mod_perl guide is probably one of the reasons that mod_perl is as popular as it is. The fact that mod_perl itself is so well documented makes people extremely comfortable using it. So similarly, I would like to see a P5EE "Guide" and this could evolve as P5EE::xxx APIs get developed... but I think the P5EE::xxx APIs will get developed a lot more slowly than the documentation could be done. > > 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. > >One of the benefits of beans, is not a technological one. Beans by >their very name create a metaphor for persistent objects, they then go >on to add more of the speciality cases that are sometimes not >considered by Perl programmers working with persistent objects and >their own home rolled persistence modules. > >And yes the last paragraph could be paraphrased as beans are good, >cause they have a neat name. ;-) OK. I've also touched on this more in the glossary post.
