* 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. > 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) > 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 > * 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. > hmm, i'm not sure if i said that, i may of said that CTO's like buzzwords, i'll go back and check after this post (apologies for not being more careful in my reply, but it is a reply to quite a long (which is good) post) > 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") > 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. ;-) Greg -- Greg McCarroll http://217.34.97.146/~gem/
