Hi, Gunther! Thanks for the great summary. I absolutely agree that CPAN should become the first stop for module search, at the same time, component map will give us better understanding what areas are grey and need to be addressed. I tried to summarize many comments and update list of components. I agree that we should separate core, and p5ee components, and tried to reflect it. It is not a flat structure for me, but rather a map like technology map in Civilization, where one technology depends on others and a *range* of those represents components/APIs we are looking at.
-- core -- Testing Documentation Exception/Error tracking Configuration/Command line options I18n/Unicode Logging and Auditing Serialization Language Introspection Development/Debug/Diagnostics -- core OR basic -- Parsers Compilers Cryptography -- basic -- Security (Authentication, Authorization, Identification and Personalization) Data/Object Persistence Database Access Data storage Sessions Caching/Optimization Network Protocols Data processing/manipulations (datatypes, strings, text, compression) XML manipulations Safe Environment Deployment Crosslanguage Interfaces (Perl and other languages) Server management -- p5ee -- Web Server Extensions Template Systems Mail services Messaging Remote Procedures and Webservices Transactions Naming and Directory services -- applications -- Workflow Management Application Management Business Management (ISBN, barcodes, cards, taxes) -- interfaces -- Graphic Interfaces Web Interfaces User Interfaces X11 Interfaces Application Interfaces (legacy and commercial systems) OS interfaces IMHO Parsers, Compilers and Cryptography belong to core section, but others may decide that basic is the best place for them. API questions is quite complex and I agree that P5EE::xxx interfaces are rather for stage2. At this point I would try to draw a component map, define what modules belong where and check current relations between those modules. If one module uses another one it uses its API. If majority of modules use some other module it sets de facto API standard. We should identify those and reuse as much as possible. I would like to see API for mail processing. I would also like to see API for MIME processing (so mail packages can use it and, for example, SOAP::Lite can use the same API, even if they use them differently). At the same time, I would rather do not have one common API for business management (imho it's area where TIMTOWTDI will play better). is this list archived somewhere? Best wishes, Paul. --- Gunther Birznieks <[EMAIL PROTECTED]> wrote: > 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 === message truncated === __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
