perl.p5ee http://www.nntp.perl.org/group/perl.p5ee/ ... Copyright 1998-2014 perl.org Mon, 15 Sep 2014 03:00:20 +0000 ask@perl.org Perl on Google App Engine: a new project by Stephen Adkins Hi,<br/><br/>I have been promoting the idea of a community project to get Perl<br/>supported on Google App Engine.<br/><br/> * http://code.google.com/p/googleappengine/issues/detail?id=34#c436<br/><br/>I have made various contacts with people inside Google, and it seems<br/>that the core App Engine team is busy with plenty of other thinigs.<br/>However, this does not stop the community from getting something<br/>started. We will likely attract perl advocates within Google as we go<br/>along, even if they are not on the App Engine team. I would like to<br/>see the effort advance until the point where it becomes a simple<br/>matter for the App Engine team to embrace Perl.<br/><br/>I have started a project for all people interested in following this<br/>effort or contributing toward it.<br/><br/> * http://code.google.com/p/perl-appengine/<br/><br/>Please visit the website, sign up for the mailing list, spread the<br/>word, and start contributing.<br/><br/>Thanks,<br/><br/>Stephen Adkins<br/>spadkins@gmail.com<br/> http://www.nntp.perl.org/group/perl.p5ee/2008/06/msg1341.html Sat, 21 Jun 2008 12:14:57 +0000 Re: Cloud Computing on Perl by Rob Nagler &gt; 1. Are there any current efforts to get it working and approved with<br/>&gt; Google AppEngine?<br/><br/>What about Leon&#39;s Amazon&#39;s S3 module?<br/><br/>http://search.cpan.org/dist/Net-Amazon-S3/<br/><br/>Also, why not generate the Python you need to solve the problem that<br/>AppEngine would enhance? AppEngine doesn&#39;t allow writing to disk or<br/>integrating with C modules (at least according to the FAQ) so it seems<br/>it has a fairly narrow application range. By generating the code, you<br/>gain access to the cloud for the problems that the cloud solves best.<br/><br/>Rob<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2008/05/msg1340.html Thu, 22 May 2008 20:43:06 +0000 Re: Cloud Computing on Perl by Stephen Adkins Hi,<br/><br/>Let me be more specific.<br/>Perl is not supported on Google AppEngine.<br/>I would like it to be supported on Google AppEngine.<br/><br/>1. Are there any current efforts to get it working and approved with<br/>Google AppEngine?<br/>2. Who would like to help with this project?<br/>3. Who else should I coordinate with in the Perl community in working on this?<br/><br/>Stephen<br/><br/>On 5/19/08, Leon Brocard &lt;acme@astray.com&gt; wrote:<br/>&gt; 2008/5/19 Stephen Adkins &lt;spadkins@gmail.com&gt;:<br/>...<br/>&gt; In my opinion CPAN already has the modules you want, anything else<br/>&gt; would be too specific to be useful.<br/>&gt;<br/>&gt;<br/>&gt; Leon<br/>&gt;<br/> http://www.nntp.perl.org/group/perl.p5ee/2008/05/msg1339.html Wed, 21 May 2008 07:10:30 +0000 Re: Cloud Computing on Perl by Leon Brocard 2008/5/19 Stephen Adkins &lt;spadkins@gmail.com&gt;:<br/><br/>&gt; &quot;Cloud Computing&quot; has arisen as a powerful new paradigm (and buzzword) [1].<br/>&gt; So here are my questions for discussion.<br/><br/>I&#39;m so far ahead of the buzzwords that I presented this talk last week<br/>at YAPC::Asia:<br/><br/> http://www.slideshare.net/acme/living-in-the-cloud/<br/><br/>In my opinion CPAN already has the modules you want, anything else<br/>would be too specific to be useful.<br/><br/>Leon<br/> http://www.nntp.perl.org/group/perl.p5ee/2008/05/msg1338.html Mon, 19 May 2008 16:26:55 +0000 Re: Cloud Computing on Perl by Scott Walters Briefly, FYI, one of my little tasks is to add session affinity to<br/>Continuity. Given a pile of servers running Continuity hosted apps,<br/>a connection to the wrong one should get you transparently proxied to<br/>the correct one for your session where your persistent execution<br/>context lives. This doesn&#39;t do anything for giving you truly global<br/>data across all nodes. That&#39;s a seperate project. I imagine<br/>global, coherent data syncronized with forks.pm between nodes across <br/>an OpenSSI cluster, but that would be a hard sell. <br/><br/>I have to say that &quot;cloud computing&quot; is a lame metaphore, a leaky<br/>abstraction, and something appealing for romantic reasons -- running code<br/>on Google&#39;s servers -- rather than practical reasons. Building and<br/>colocating servers is generally the least concern of a significant<br/>web effort, and not having control, if it were a concern, would be<br/>a large one. Hitching your wagon to Google App Engine&#39;s horse<br/>would be a major commitment with no easy exit stragetegy. Two<br/>programmers can&#39;t even agree on an ORM. This is the modern counterpart<br/>to Geocities. Not to discourage you from your task too much -- do <br/>it if you want to, but as they say, beware the hype.<br/><br/>Hmm... adding some map/reduce crap to Continuity would be interesting.<br/>And I guess I should be thinking about a non-blocking interface to<br/>that distributed cache thing everyone is using...<br/><br/>Good luck...<br/><br/>-scott<br/><br/>On 0, Stephen Adkins &lt;spadkins@gmail.com&gt; wrote:<br/>&gt; Hi,<br/>&gt; <br/>&gt; I haven&#39;t sent anything out through the P5EE mailing list in a couple of years.<br/>&gt; I&#39;m using it now to raise a related issue.<br/>&gt; <br/>&gt; &quot;Cloud Computing&quot; has arisen as a powerful new paradigm (and buzzword) [1].<br/>&gt; So here are my questions for discussion.<br/>&gt; <br/>&gt; 1. Does anyone know if anyone in the Perl community is working with Google<br/>&gt; to get Perl certified for use in Google App Engine? [2]<br/>&gt; (It currently only supports Python.)<br/>&gt; <br/>&gt; 2. If I were going to try to organize a project (&quot;Cloud Computing on Perl&quot;),<br/>&gt; are there others who would like to participate? (I would imagine that such<br/>&gt; a project would address a variety of cloud computing platforms [3] [4]<br/>&gt; including Free Software DIY clouds.)<br/>&gt; <br/>&gt; 3. If I were organizing this, does anyone have any particular people/projects<br/>&gt; with a vested interest to suggest that I should coordinate this with?<br/>&gt; <br/>&gt; Stephen<br/>&gt; <br/>&gt; [1] http://en.wikipedia.org/wiki/Cloud_computing<br/>&gt; [2] http://code.google.com/appengine/docs/whatisgoogleappengine.html<br/>&gt; [3] http://www.amazon.com/gp/browse.html?node=201590011<br/>&gt; [4] http://en.wikipedia.org/wiki/Cloud_computing#Cloud_services<br/> http://www.nntp.perl.org/group/perl.p5ee/2008/05/msg1337.html Mon, 19 May 2008 03:19:20 +0000 Cloud Computing on Perl by Stephen Adkins Hi,<br/><br/>I haven&#39;t sent anything out through the P5EE mailing list in a couple of years.<br/>I&#39;m using it now to raise a related issue.<br/><br/>&quot;Cloud Computing&quot; has arisen as a powerful new paradigm (and buzzword) [1].<br/>So here are my questions for discussion.<br/><br/> 1. Does anyone know if anyone in the Perl community is working with Google<br/> to get Perl certified for use in Google App Engine? [2]<br/> (It currently only supports Python.)<br/><br/> 2. If I were going to try to organize a project (&quot;Cloud Computing on Perl&quot;),<br/> are there others who would like to participate? (I would imagine that such<br/> a project would address a variety of cloud computing platforms [3] [4]<br/> including Free Software DIY clouds.)<br/><br/> 3. If I were organizing this, does anyone have any particular people/projects<br/> with a vested interest to suggest that I should coordinate this with?<br/><br/>Stephen<br/><br/>[1] http://en.wikipedia.org/wiki/Cloud_computing<br/>[2] http://code.google.com/appengine/docs/whatisgoogleappengine.html<br/>[3] http://www.amazon.com/gp/browse.html?node=201590011<br/>[4] http://en.wikipedia.org/wiki/Cloud_computing#Cloud_services<br/> http://www.nntp.perl.org/group/perl.p5ee/2008/05/msg1336.html Mon, 19 May 2008 02:31:03 +0000 Question about App-Context by Daniel Ruoso Is it possible to have one single App-Context for both providing a GUI<br/>client and SOAP services? Or two different instances would be needed?<br/><br/>I mean, the GUI and the SOAP services are just different services<br/>running on the same context (in my desired environment). This would be<br/>good to avoid IPC if the two processes would be running in the same<br/>&quot;node&quot;...<br/><br/>daniel<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2005/08/msg1335.html Fri, 19 Aug 2005 13:00:49 +0000 What I see as a desired environment (Was: Re: Introducing myself) by Daniel Ruoso Em Qui, 2005-08-18 &agrave;s 19:19 -0300, Daniel Ruoso escreveu:<br/>&gt; It seems to be dealing with the exact same problem I&#39;d like to deal<br/>&gt; with Oak2<br/><br/>Well,<br/><br/>this is a data dump of my brain at this moment... :)<br/><br/>* The application is distributed among nodes.<br/>* Each node can see any object (remote or local, in a transparent way)<br/>* Use of UDDI servers to see where is what<br/>* A GUI client *is* an application node, and can provide services itself<br/>(in a store, the manager&#39;s node can ask the operator&#39;s node for an<br/>information)<br/>* So is a Web client.<br/>* So is a server that is just providing services for the gui and web<br/>clients (or for other server nodes).<br/>* The information can be spreaded (this is more usefull for e-gov<br/>environments, as we don&#39;t want to control the citizens, but the gov<br/>actions...)<br/>* Distributed transactions over different nodes.<br/>* SOAP over SSL, using the SSL keys to certify nodes. (I mean, having a<br/>SSL private key for each node, so you can know if that message was sent<br/>by that node. Also allowing setting trust levels for the keys, so it&#39;s<br/>possible to treat differently a server in a datacenter and a desktop<br/>machine.)<br/>* Definition of a business flow using events generated by objects. The<br/>listeners for that events can be dinamically attached. (For instance, if<br/>I have a purchase order confirmed, the finances dept should be notified<br/>about it&#39;s value, but I could just disable it, if the finances dept is<br/>not using the system yet (during the transition from an old system), or<br/>change to the code that integrates with other legacy systems, or even<br/>having a different way of dealing with this information)<br/>* Meta-data for entities relationships, so new relationships can be<br/>defined dinamically. This meta-data defines which type of object would<br/>handle it&#39;s data when other node is looking at it (a GUI node, for<br/>instance). (A account payable can refer to a Supplier, to an Employee or<br/>to the Investors, but its logic is the same in all cases).<br/><br/>What do you think?<br/><br/>daniel<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2005/08/msg1334.html Thu, 18 Aug 2005 15:54:30 +0000 Introducing myself by Daniel Ruoso Hi,<br/><br/>I&#39;m the primary author of the Perl Oak Component Tree (mentioned in your<br/>&quot;Components&quot; page), and I&#39;m working with Enterprise Systems since 1999.<br/>I started the Oak Project in 2001, and the first version is stalled. I<br/>mean, some conceptual problems raised, and I&#39;m not going to continue on<br/>it. I&#39;m working (sadly) with J2EE (JBOSS) since jan 2003, and I saw that<br/>it should be really bigger than it was.<br/><br/>I was starting to plan the second version of Oak, which would be named<br/>Oak2 (very original, isn&#39;t it?). I did write some documentation raising<br/>the main points I&#39;d like to see in Oak2[1]. But I finally came to the<br/>p5ee site and take a deeper look on it. It seems to be dealing with the<br/>exact same problem I&#39;d like to deal with Oak2, so I asked myself, why<br/>Oak2 since there is this project already...<br/><br/>Well, it seems that there is already a lot of things done, but I really<br/>have some problems understanding exactly how it works. I couldn&#39;t find a<br/>more descriptive documentation of its architecture... So... Is there any<br/>place you can point me? If there isn&#39;t, would you mind in giving me some<br/>general ideas of the architecture?<br/><br/>daniel<br/><br/>[1]<br/>http://cvs.sourceforge.net/viewcvs.py/*checkout*/perl-oak/Oak/liboak2-perl/doc/basics.html?content-type=text%2Fplain&amp;rev=1.1<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2005/08/msg1333.html Thu, 18 Aug 2005 15:20:30 +0000 Re: Anyone up for a P5EE BOF discussion at YAPC::NA? by Scott Walters Hi all,<br/><br/>For what every little it&#39;s worth, I&#39;m hoping to be there in my unofficial capacity<br/>as dork-behind-perldesignpatterns.com. I&#39;ll monitor my email as usual. Never been<br/>before so I&#39;d be nice to have some driving agenda pushing me towards people.<br/><br/>-scott<br/><br/>On 0, Richard Dice &lt;rdice@pobox.com&gt; wrote:<br/>&gt; <br/>&gt; &gt; Tomorrow is the last day to register for YAPC::NA and get in<br/>&gt; &gt; on the group block at the hotel.<br/>&gt; <br/>&gt; I am attempting to renegotiate this with the hotel. I have high hopes that this<br/>&gt; will be successful, but as of right now, the end of this week is the deadline. <br/>&gt; That doesn&#39;t mean that the rooms will disappear entirely - only that they will<br/>&gt; no longer be pre-reserved for YAPC attendees. However, I expect public-at-large<br/>&gt; people will be quite aggressive going after rooms at this facility, so they<br/>&gt; won&#39;t last long. (1/2 life of maybe 4 days?)<br/>&gt; <br/>&gt; &gt; I wasn&#39;t planning on going.<br/>&gt; &gt; <br/>&gt; &gt; However, if there were enough people on this list who are<br/>&gt; &gt; going who would like to jump-start the P5EE effort with a<br/>&gt; &gt; BOF (Bird of a Feather) discussion there, I would consider<br/>&gt; &gt; going.<br/>&gt; &gt; <br/>&gt; &gt; * Is anyone going?<br/>&gt; <br/>&gt; I am. (Somewhat obviously.)<br/>&gt; <br/>&gt; &gt; * Do you believe that a conversation (maybe one evening<br/>&gt; &gt; after the conference activities) on P5EE would be<br/>&gt; &gt; valuable?<br/>&gt; <br/>&gt; I might recommend something on Sunday. We have many evening activities planned<br/>&gt; for the conference. (Or, the BOF could be held on the cruise boat where the<br/>&gt; Tuesday night banquet will be held. P5EE people could just sort of gang up all<br/>&gt; in the same place and talk before or after dinner is served.)<br/>&gt; <br/>&gt; &gt; P.S. As someone who advocates Perl for enterprise software<br/>&gt; &gt; uses and encounters skepticism regularly, I still believe<br/>&gt; &gt; in this project. However, we need to build a community in<br/>&gt; &gt; order for it to be successful.<br/>&gt; <br/>&gt; When the schedule was programmed it seemed to me like there were a few talks<br/>&gt; that were P5EE-ish: See &quot;Perl DateTime Project&quot; and &quot;Managing Email with Perl&quot;,<br/>&gt; 3:15pm onwards in the Giovanni room. <br/>&gt; http://yapc.org/America/schedule-2005/day2.html It&#39;s not obvious, but if you<br/>&gt; click on the talk titles you&#39;ll get descriptions of the talks.<br/>&gt; <br/>&gt; I grouped these two together one after the other as a kind of thematic nod to P5EE.<br/>&gt; <br/>&gt; Between the efforts described in those talks and Damian&#39;s upcoming &quot;Perl Best<br/>&gt; Practices&quot; book (to be released late summer / early fall), I feel as though some<br/>&gt; slow progress is being made in the general viscinity of P5EE.<br/>&gt; <br/>&gt; Cheers,<br/>&gt; Richard<br/>&gt; <br/>&gt; <br/>&gt; -------------------------------------------------<br/>&gt; This mail sent through IMP: http://horde.org/imp/<br/> http://www.nntp.perl.org/group/perl.p5ee/2005/05/msg1332.html Fri, 13 May 2005 02:38:14 +0000 Re: Anyone up for a P5EE BOF discussion at YAPC::NA? by Chris Winters * Stephen Adkins (stephen.adkins@officevision.com) [050512 10:31]:<br/>&gt; Hi,<br/>&gt; <br/>&gt; Tomorrow is the last day to register for YAPC::NA and get in<br/>&gt; on the group block at the hotel.<br/>&gt; I wasn&#39;t planning on going.<br/>&gt; <br/>&gt; However, if there were enough people on this list who are<br/>&gt; going who would like to jump-start the P5EE effort with a<br/>&gt; BOF (Bird of a Feather) discussion there, I would consider<br/>&gt; going.<br/>&gt; <br/>&gt; * Is anyone going?<br/>&gt; * Do you believe that a conversation (maybe one evening<br/>&gt; after the conference activities) on P5EE would be<br/>&gt; valuable?<br/><br/>I&#39;m going. A conversation could be valuable and I&#39;ll certainly<br/>attend[1], but I&#39;m not sure it&#39;ll jumpstart anything. It seems to me<br/>like the P5EE effort suffers from (a) Perl folks being suspicious of<br/>standards (and who can blame them, seeing what&#39;s happened in the Java<br/>world), and (b) lack of tuits.<br/><br/>Chris<br/><br/>[1] I&#39;m coming in Sunday evening and leaving early Thursday morning.<br/><br/>-- <br/>Chris Winters (http://www.cwinters.com)<br/>Building enterprise-capable snack solutions since 1988<br/> http://www.nntp.perl.org/group/perl.p5ee/2005/05/msg1331.html Fri, 13 May 2005 02:37:10 +0000 Re: Anyone up for a P5EE BOF discussion at YAPC::NA? by Richard Dice <br/>&gt; I&#39;m also giving a talk about MVC frameworks for web development. I<br/>&gt; think there was quite a bit of material last year too.<br/><br/>Good point, Perrin. Thanks for bringing this up. We have a lot of talks<br/>specifically about CGI::Application this year, which was not a function of our<br/>predisposition on this end. Rather, it&#39;s because we got a lot of<br/>CGI::Application-related submissions in the CFP. That might say something about<br/>the state of the community.<br/> <br/>&gt; Perl Medic is the best book I&#39;ve read about enterprise perl.<br/><br/>Interesting... thanks for putting this emphasis on it. Peter Scott (the author)<br/>is giving a talk on Monday morning, which will no doubt have some relationship<br/>to this topic.<br/><br/>Cheers,<br/>Richard<br/><br/><br/><br/><br/>-------------------------------------------------<br/>This mail sent through IMP: http://horde.org/imp/<br/> http://www.nntp.perl.org/group/perl.p5ee/2005/05/msg1330.html Thu, 12 May 2005 11:24:58 +0000 Re: Anyone up for a P5EE BOF discussion at YAPC::NA? by Perrin Harkins On Thu, 2005-05-12 at 13:16 -0400, Richard Dice wrote:<br/>&gt; When the schedule was programmed it seemed to me like there were a few talks<br/>&gt; that were P5EE-ish: See &quot;Perl DateTime Project&quot; and &quot;Managing Email with Perl&quot;,<br/>&gt; 3:15pm onwards in the Giovanni room. <br/>&gt; http://yapc.org/America/schedule-2005/day2.html It&#39;s not obvious, but if you<br/>&gt; click on the talk titles you&#39;ll get descriptions of the talks.<br/>&gt; <br/>&gt; I grouped these two together one after the other as a kind of thematic nod to P5EE.<br/><br/>I&#39;m also giving a talk about MVC frameworks for web development. I<br/>think there was quite a bit of material last year too.<br/><br/>&gt; Between the efforts described in those talks and Damian&#39;s upcoming &quot;Perl Best<br/>&gt; Practices&quot; book (to be released late summer / early fall), I feel as though some<br/>&gt; slow progress is being made in the general viscinity of P5EE.<br/><br/>Perl Medic is the best book I&#39;ve read about enterprise perl.<br/><br/>- Perrin<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2005/05/msg1329.html Thu, 12 May 2005 11:00:08 +0000 Re: Anyone up for a P5EE BOF discussion at YAPC::NA? by Richard Dice <br/>&gt; Tomorrow is the last day to register for YAPC::NA and get in<br/>&gt; on the group block at the hotel.<br/><br/>I am attempting to renegotiate this with the hotel. I have high hopes that this<br/>will be successful, but as of right now, the end of this week is the deadline. <br/>That doesn&#39;t mean that the rooms will disappear entirely - only that they will<br/>no longer be pre-reserved for YAPC attendees. However, I expect public-at-large<br/>people will be quite aggressive going after rooms at this facility, so they<br/>won&#39;t last long. (1/2 life of maybe 4 days?)<br/><br/>&gt; I wasn&#39;t planning on going.<br/>&gt; <br/>&gt; However, if there were enough people on this list who are<br/>&gt; going who would like to jump-start the P5EE effort with a<br/>&gt; BOF (Bird of a Feather) discussion there, I would consider<br/>&gt; going.<br/>&gt; <br/>&gt; * Is anyone going?<br/><br/>I am. (Somewhat obviously.)<br/><br/>&gt; * Do you believe that a conversation (maybe one evening<br/>&gt; after the conference activities) on P5EE would be<br/>&gt; valuable?<br/><br/>I might recommend something on Sunday. We have many evening activities planned<br/>for the conference. (Or, the BOF could be held on the cruise boat where the<br/>Tuesday night banquet will be held. P5EE people could just sort of gang up all<br/>in the same place and talk before or after dinner is served.)<br/><br/>&gt; P.S. As someone who advocates Perl for enterprise software<br/>&gt; uses and encounters skepticism regularly, I still believe<br/>&gt; in this project. However, we need to build a community in<br/>&gt; order for it to be successful.<br/><br/>When the schedule was programmed it seemed to me like there were a few talks<br/>that were P5EE-ish: See &quot;Perl DateTime Project&quot; and &quot;Managing Email with Perl&quot;,<br/>3:15pm onwards in the Giovanni room. <br/>http://yapc.org/America/schedule-2005/day2.html It&#39;s not obvious, but if you<br/>click on the talk titles you&#39;ll get descriptions of the talks.<br/><br/>I grouped these two together one after the other as a kind of thematic nod to P5EE.<br/><br/>Between the efforts described in those talks and Damian&#39;s upcoming &quot;Perl Best<br/>Practices&quot; book (to be released late summer / early fall), I feel as though some<br/>slow progress is being made in the general viscinity of P5EE.<br/><br/>Cheers,<br/>Richard<br/><br/><br/>-------------------------------------------------<br/>This mail sent through IMP: http://horde.org/imp/<br/> http://www.nntp.perl.org/group/perl.p5ee/2005/05/msg1328.html Thu, 12 May 2005 10:23:28 +0000 Anyone up for a P5EE BOF discussion at YAPC::NA? by Stephen Adkins Hi,<br/><br/>Tomorrow is the last day to register for YAPC::NA and get in<br/>on the group block at the hotel.<br/>I wasn&#39;t planning on going.<br/><br/>However, if there were enough people on this list who are<br/>going who would like to jump-start the P5EE effort with a<br/>BOF (Bird of a Feather) discussion there, I would consider<br/>going.<br/><br/> * Is anyone going?<br/> * Do you believe that a conversation (maybe one evening<br/> after the conference activities) on P5EE would be<br/> valuable?<br/><br/>-- <br/>Stephen Adkins &lt;stephen.adkins@officevision.com&gt;<br/>OfficeVision.com<br/><br/>P.S. As someone who advocates Perl for enterprise software<br/>uses and encounters skepticism regularly, I still believe<br/>in this project. However, we need to build a community in<br/>order for it to be successful.<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2005/05/msg1327.html Thu, 12 May 2005 07:19:21 +0000 Reminder: Yet Another Perl Conference in Toronto, June 27 - 29 by Gerard Lim Yet Another YAPC::NA 2005 Conference Reminder<br/>---------------------------------------------<br/><br/>YAPC::NA 2005 is Yet Another Perl Conference, North America,<br/>this year to be held in downtown Toronto, Ontario, Canada,<br/>Mon - Wed 27 - 29 June 2005.<br/><br/> Important Dates/Deadlines<br/> -------------------------<br/> April 18 -- deadline for paper submissions<br/> May 12 -- last day of guaranteed accommodations<br/><br/>YAPC::NA is a grassroots, all-volunteer conference. The<br/>speaker quality is high, the participants lively, and there<br/>are many extra social activities scheduled. We expect a<br/>bit over 400 people this year, and registration is proceeding<br/>faster this year than in the past.<br/><br/>The registration cost is USD$85. Information on registration:<br/><br/> http://yapc.org/America/register-2005.shtml<br/> http://yapc.org/America/registration-announcement-2005.txt<br/><br/>Direct link to registration:<br/><br/> <br/>http://donate.perlfoundation.org/index.pl?node=registrant%20info&amp;conference_id=423<br/><br/>Want to be a speaker? Deadline for proposal submission<br/>is April 18, just over 1 week from now. Go to:<br/> http://yapc.org/America/cfp-2005.shtml<br/><br/>Need accommodations in Toronto? Go to:<br/><br/> http://yapc.org/America/accommodations-2005.shtml<br/><br/>If you book before May 13 you will be guaranteed a hotel<br/>space. After that getting accommodations will become<br/>progressively more difficult. Prices we have arranged<br/>are in two different price ranges: approximately US$50<br/>for a dorm room, US$72 for a decent hotel room. All<br/>accommodations are very nearby the conference venue.<br/><br/>This message comes from the YAPC::NA 2005 organizers in<br/>Toronto.pm, http://to.pm.org/, on behalf of The Perl<br/>Foundation, http://www.perlfoundation.org/<br/>We look forward to seeing you in Toronto!<br/><br/>If you have any questions please contact na-help@yapc.org<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2005/04/msg1326.html Sun, 10 Apr 2005 09:14:08 +0000 Yet Another Perl Conference, North America, 2005 Registration now open by glim ----------&gt;<br/> Yet Another Perl Conference, North America, 2005 Registration now<br/> open.<br/><br/> Conference dates: Monday - Wednesday 27 - 29 June 2005<br/><br/> Location: 89 Chestnut Street http://89chestnut.com/<br/> University of Toronto<br/> Toronto, Ontario, Canada<br/><br/> Info at: http://yapc.org/America<br/><br/> Direct registration: <br/>http://donate.perlfoundation.org/index.pl?node=registrant%20info&amp;conference_id=423<br/><br/> Full registration fee $85 (USD)<br/><br/> Book now for great deals on accommodations and ensure a space for<br/> yourself.<br/><br/> Speaking slots are still open. If you would like to present at<br/> YAPC::NA 2005, see: http://yapc.org/America/cfp-2005.shtml<br/><br/> Details of this announcement:<br/> http://yapc.org/America/registration-announcement-2005.txt<br/> &lt;----------<br/><br/>More Details<br/>============<br/><br/>Registration for YAPC::NA (Yet Another Perl Conference, North America)<br/>2005 in Toronto, Ontario, Canada is now open.<br/><br/>The conference registration price is USD$85. This price includes<br/>admission to all aspects of the conference, respectable amounts of<br/>catering, several activities and a few conference goodies.<br/><br/>The YAPC North America 2005 conference features...<br/><br/> * Fantastic speakers<br/><br/> + most are the core creators of the technology on which<br/> they present<br/><br/> + many are professional IT authors, trainers and conference<br/> speakers<br/><br/> * An excellent learning opportunity<br/><br/> * A chance to meet Perl professionals from all over North America<br/> and the world<br/><br/> + YAPC attendees tend to be very involved in Perl and so are<br/> another great way to learn more about what the language<br/> has to offer beyond just what the speakers have to say<br/><br/> * Extra-curricular / after hours activities<br/><br/> * A great location in downtown Toronto<br/><br/>All this, and the price is more than an order of magnitude cheaper<br/>than what commercial conferences can offer. This is because YAPC is a<br/>100% volunteer effort, both from its organizers and its speakers.<br/>Quality is *not* sacrificed to achieve this stunning level of<br/>affordability.<br/><br/>YAPC provides the best value-for-dollar in IT conferences. And it&#39;s a<br/>ton of fun, too.<br/><br/>The dates of the conference are Monday - Wednesday 27-29 June<br/>2005. The location is 89 Chestnut Street in downtown Toronto, Ontario,<br/>Canada. (Note that a different date block was previously announced;<br/>we moved the conference date to accommodate venue availability.)<br/><br/>http://89chestnut.com/ -- a facility within the University of Toronto<br/><br/>If you are at all interested in attending the conference...<br/><br/> Book now!<br/><br/> Book now!<br/><br/> Book now!<br/><br/>We have room for about 400 attendees and we hope to sell out well<br/>in advance of the late June conference date. However, the critical<br/>matter is that of hotels.<br/><br/>The YAPC::NA 2005 organizers have made group arrangements with several<br/>facilities around the city to provide _excellent_ quality<br/>accommodations in _very_ convenient locations at _terrific_ prices for<br/>the _full_ capacity of conference attendees (around 400 people).<br/><br/>(Finding, booking and paying accommodations is the responsibility of<br/>the attendees, but we will provide you with a list of the hotels and<br/>university dorms to try first based on our group arrangement with them<br/>when you register for the conference. Also, see the web site at<br/>http://yapc.org/America/accommodations-2005.shtml. More details will be<br/>up shortly. The dorm option will be approx. C$55/night, the hotel<br/>options will be more like C$90/night, and for slightly different prices<br/>there will be options for putting more than 1 person in a room. Exact<br/>details and how to book will be emailed directly to people who have<br/>registered for the conference as soon as they become available.)<br/><br/>*The catch is -- book now!!* The group reservations will expire in<br/>early May, at which point in time the group rates will mostly still<br/>apply, but the rooms will be given out on an &quot;availability basis&quot;.<br/>Which means that someone else outside of the YAPC group can book the<br/>rooms as well.<br/><br/>Make no mistake -- the rooms *will* be sold. Toronto is a very active<br/>conference city in the summer and there will be _no_ guarantee of<br/>vacancies either at the facilities we made arrangements with or<br/>anywhere else in the city if you leave it to within 6 weeks of the<br/>conference date. So, if you want to save yourself the likely-fruitless<br/>headache of scrambling around looking for accommodations at the last<br/>minute,<br/><br/> Book now!<br/><br/> Book now!<br/><br/> Book now!<br/><br/>Have any questions? Email na-help@yapc.org for more details.<br/><br/>Additionally, we are still welcoming submissions for proposals via:<br/><br/> http://yapc.org/America/cfp-2005.shtml<br/><br/>The close of the call-for-papers is April 18, 2005 at 11:59 pm<br/>(Toronto time).<br/><br/>If you have any questions regarding the call-for-papers or speaking at<br/>YAPC::NA 2005 please email na-author@yapc.org<br/><br/>We would love to hear from potential sponsors. Please contact the<br/>organizers at na-sponsor@yapc.org to learn about the benefits of<br/>sponsorship.<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2005/03/msg1325.html Sat, 19 Mar 2005 12:49:15 +0000 [OT] Yet Another Perl Conference North America 2005 announces call-for-papers by glim YAPC::NA 2005 (Yet Another Perl Conference, North America) has just<br/> released its call-for-papers; potential and aspiring speakers can<br/> submit a presentation proposal via:<br/><br/> http://yapc.org/America/cfp-2005.shtml<br/><br/> The dates of the conference are Monday - Wednesday 27-29 June 2005.<br/> The location will be in downtown Toronto, Ontario, Canada. (Note that<br/> a different date block was previously announced, but has been moved to<br/> accomodate venue availability.)<br/><br/> The close of the call-for-papers is April 18, 2005 at 11:59 pm.<br/><br/> If you have any questions regarding the call-for-papers or speaking at<br/> YAPC::NA 2005 please email na-author@yapc.org<br/><br/> We would love to hear from potential sponsors. Please contact the<br/> organizers at na-sponsor@yapc.org to learn about the benefits of<br/> sponsorship.<br/><br/> Other information regarding the conference (e.g. venue, registration<br/> specifics) will be announced soon.<br/><br/> We look forward to your submissions and a great conference!<br/><br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2005/02/msg1324.html Tue, 22 Feb 2005 20:54:53 +0000 POE as application server by Bas Schulte Hi all,<br/><br/>in my explorations into the world of POE I ran into this: <br/>http://search.cpan.org/~kaare/Business-Bof-0.01<br/><br/>It&#39;s an application server type of app that you can call using SOAP <br/>clients.<br/><br/>Found something else here: http://pied.nu/Perl/JAAS<br/><br/>I think this could be interesting as an application server type of <br/>thing.<br/><br/>Anyone care to share experience with these? Or similar POE-based <br/>solutions?<br/><br/>I hope to find some time to put our request-processing apache-based <br/>&quot;app server&quot; (most of the &quot;web&quot; stuff hasn&#39;t been compiled in httpd) <br/>code into a POE server, to see how it performs and how the additional <br/>stuff adds value to that picture.<br/><br/>Cheers,<br/><br/>Bas.<br/><br/>ps. I still have difficulties with POE&#39;s concepts and naming, hope to <br/>get that down soon.<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1323.html Thu, 30 Dec 2004 02:44:19 +0000 Re: FW: The P5EE dream is alive, was: ping... by Scott Walters Hi Perrin,<br/><br/>I have no desire to suggest another goal, thanks. I was just trying to<br/>put context to the present discussion for my own sake. I&#39;ll try to<br/>keep up with the discussion better.<br/><br/>-scott<br/><br/>On 0, Perrin Harkins &lt;perrin@elem.com&gt; wrote:<br/>&gt; Scott Walters wrote:<br/>&gt; &gt;Is the purpose of P5EE to write yet another object framework or is it<br/>&gt; &gt;to recommend a standard library of other objects and advocate an<br/>&gt; &gt;enterprisish API? <br/>&gt; <br/>&gt; When we discussed this at The Perl Conference a few years back, it was <br/>&gt; determined that the only thing everyone there really wanted out of it <br/>&gt; was marketing, i.e. they want people to think of Perl as a valid option <br/>&gt; for enterprise work. You are welcome to propose another goal though.<br/>&gt; <br/>&gt; - Perrin<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1322.html Thu, 09 Dec 2004 15:41:22 +0000 Re: FW: The P5EE dream is alive, was: ping... by Richard Dice Perrin said:<br/><br/>&gt; When we discussed this at The Perl Conference a few years back, it was <br/>&gt; determined that the only thing everyone there really wanted out of it <br/>&gt; was marketing, i.e. they want people to think of Perl as a valid option <br/>&gt; for enterprise work. You are welcome to propose another goal though.<br/><br/>This is my recollection from that discussion as well.<br/><br/>I think where it went next was a discussion of what it would take to <br/>make a marketing case for Perl as being appropriate for enterprise work. <br/> My recollection of this is a bit more vague, but to reconstruct this <br/>as a composite of what was probably said plus my own opinions on the <br/>matter, it came down to two pieces:<br/><br/> 1. Marketing qua marketing -- i.e. getting a bazillion dollar budget to<br/> take out glossy ads in CIO Magazine and related. Let me know when<br/> this happens. :-)<br/><br/> 2. Building a &quot;P5EE Product&quot; that can be marketed<br/><br/>As for (2.), I my 0-th order approximation of what is needed along these <br/>lines is<br/><br/> * choose a set of CPAN modules that does what is needed (PNATTMBTC)<br/> * fill in the gaps as needed<br/> * subclass to a P5EE namespace<br/> * unify quirks in the calling API (i.e. the P5EE namespace has a<br/> bit of a translation layer to each individual module from a<br/> common-ish API, a la OpenPlugin)<br/> * make sure that the test suite for all the above is complete<br/> * do a license audit of everything here (i.e. probably make sure<br/> that everything is Perl Artistic)<br/> * having an easily-installable bundle, like a PAR<br/> * get a good set of docs both included and online for all this<br/><br/>Cheers,<br/>Richard<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1321.html Thu, 09 Dec 2004 09:30:04 +0000 Re: FW: The P5EE dream is alive, was: ping... by Perrin Harkins Scott Walters wrote:<br/>&gt; Is the purpose of P5EE to write yet another object framework or is it<br/>&gt; to recommend a standard library of other objects and advocate an<br/>&gt; enterprisish API? <br/><br/>When we discussed this at The Perl Conference a few years back, it was <br/>determined that the only thing everyone there really wanted out of it <br/>was marketing, i.e. they want people to think of Perl as a valid option <br/>for enterprise work. You are welcome to propose another goal though.<br/><br/>- Perrin<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1320.html Thu, 09 Dec 2004 08:34:01 +0000 Re: FW: The P5EE dream is alive, was: ping... by Scott Walters Folks,<br/><br/>Is the purpose of P5EE to write yet another object framework or is it<br/>to recommend a standard library of other objects and advocate an<br/>enterprisish API? <br/><br/>-scott<br/><br/>On 0, David Christensen &lt;dpchrist@holgerdanske.com&gt; wrote:<br/>&gt; Richard Dice wrote:<br/>&gt; &gt; What kind of features are you looking for in such a framework?<br/>&gt; <br/>&gt; Tough question. I guess it really depends upon my perspective (coder)<br/>&gt; and what I&#39;m trying to build (ideally, anything that can be seen on the<br/>&gt; web now or in the future).<br/>&gt; <br/>&gt; <br/>&gt; I&#39;ll start by throwing out a rough wish-list that we can all critique<br/>&gt; and modify:<br/>&gt; <br/>&gt; 1. On-line user/support community.<br/>&gt; <br/>&gt; 2. Separation of function (code), presentation (templates), and content<br/>&gt; (database).<br/>&gt; <br/>&gt; 3. Genuine Perl; preferably 5.8.<br/>&gt; <br/>&gt; 4. Open-source de-facto standard language(s) and tools for the<br/>&gt; framework itself and all associated infrastructure used to work on it<br/>&gt; and the products built with it.<br/>&gt; <br/>&gt; 5. Perl Artistic License.<br/>&gt; <br/>&gt; 6. Strong security.<br/>&gt; <br/>&gt; 7. Documentation -- architecture, design, implementation, test,<br/>&gt; programmer&#39;s guide, designer&#39;s guide, author/editor&#39;s guide,<br/>&gt; administrator&#39;s manual, etc..<br/>&gt; <br/>&gt; 8. OO design and implementation.<br/>&gt; <br/>&gt; 9. Ability to sub-class to modify functionality.<br/>&gt; <br/>&gt; 10. Ability to create and easily add/ remove/ manage/ monitor plug-ins<br/>&gt; to add functionality.<br/>&gt; <br/>&gt; 11. Built-in functionality: user accounts, groups, privilege levels,<br/>&gt; home pages/ sub-sites, storage management (quotas), search,<br/>&gt; friendly/short URL&#39;s, search engine friendly/compatible.<br/>&gt; <br/>&gt; 12. Plug-in functionality: threaded forums, issue tracking/ticketing<br/>&gt; system, CVS client, photo gallery.<br/>&gt; <br/>&gt; 13. Version control and content management system capabilities.<br/>&gt; <br/>&gt; 14. Information architecture hooks.<br/>&gt; <br/>&gt; 15. Off-line and on-line development/debugging/test environments for<br/>&gt; coders and designers.<br/>&gt; <br/>&gt; 16. On-line WSIWYG development environment and workflow for<br/>&gt; authors/editors.<br/>&gt; <br/>&gt; 17. On-line WSIWYG development/debugging environment for novice users to<br/>&gt; create simplified/restricted code, presentation, and/or content.<br/>&gt; <br/>&gt; 18. Comprehensive regression test suite for framework and anything<br/>&gt; distributed/supported with it. <br/>&gt; <br/>&gt; 19. Ability to run on well-featured shared Linux web hosting accounts.<br/>&gt; <br/>&gt; 20. Ability to backup and restore while operational.<br/>&gt; <br/>&gt; <br/>&gt; David<br/>&gt; <br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1319.html Thu, 09 Dec 2004 08:25:48 +0000 Re: PHP is the scourge by Dave Rolsky On Tue, 7 Dec 2004, Perrin Harkins wrote:<br/><br/>&gt; On Tue, 2004-12-07 at 10:13 -0600, Dave Rolsky wrote:<br/>&gt;&gt; I&#39;ve never written an app for a client that started on one backend and<br/>&gt;&gt; moved to another.<br/>&gt;<br/>&gt; I have. I helped move an app from MySQL to Oracle once. It took a lot<br/>&gt; of work to get rid of mysql-isms, but the DBI code itself hardly changed<br/>&gt; at all. I would agree with the earlier poster that the level of<br/>&gt; abstraction DBI provides is really helpful when this sort of thing comes<br/>&gt; along. I suspect Pear::DB is fine for this too.<br/><br/>I think the consistency of DB is helpful even if you never move an app <br/>from one DBMS to another. Chances are you&#39;ll still end up using more than <br/>one in a career, and being able to connect and send queries with the same <br/>API is great. What I don&#39;t think is attempting to mask _all_ the <br/>differences (particularly in SQL itself) between various DBMS backends.<br/><br/><br/>-dave<br/><br/>/*===========================<br/>VegGuide.Org<br/>Your guide to all that&#39;s veg.<br/>===========================*/<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1318.html Wed, 08 Dec 2004 08:40:51 +0000 Re: The P5EE dream is alive, was: ping... by Chris Winters I&#39;ll pipe in with some answers for OpenInteract2 (the latest beta of <br/>which was just released to CPAN, FWIW). You might have seen <br/>OpenInteract 1.x in your survey but this version has some dramatic <br/>differences in architecture and documentation. (It&#39;s pretty much a <br/>rewrite, although a number of core concepts remain.)<br/><br/>On Dec 6, 2004, at 11:05 PM, David Christensen wrote:<br/>&gt; I&#39;ll start by throwing out a rough wish-list that we can all critique<br/>&gt; and modify:<br/>&gt;<br/>&gt; 1. On-line user/support community.<br/><br/>Sourceforge, JIRA issue tracking, mailing lists, usual.<br/><br/>&gt; 2. Separation of function (code), presentation (templates), and <br/>&gt; content<br/>&gt; (database).<br/><br/>You bet.<br/><br/>&gt; 3. Genuine Perl; preferably 5.8.<br/><br/>It&#39;s pure-perl. I dunno what 5.8-isms are useful.<br/><br/>&gt; 4. Open-source de-facto standard language(s) and tools for the<br/>&gt; framework itself and all associated infrastructure used to work on it<br/>&gt; and the products built with it.<br/><br/>It&#39;s all Perl, although the templating engine is Template Toolkit (by <br/>default) and configuration is mostly modified-INI files.<br/><br/>&gt; 5. Perl Artistic License.<br/><br/>Yes.<br/><br/>&gt; 6. Strong security.<br/><br/>Do you mean the code itself is secure? As far as I know. I think <br/>there&#39;s only one place where we shell out to do something and that will <br/>be gone soon.<br/><br/>&gt; 7. Documentation -- architecture, design, implementation, test,<br/>&gt; programmer&#39;s guide, designer&#39;s guide, author/editor&#39;s guide,<br/>&gt; administrator&#39;s manual, etc..<br/><br/>Architecture, design and programmer&#39;s guides are pretty solid. Nothing <br/>on testing. Not terribly much on gui-type authoring (since we rely on <br/>other templating engines for us).<br/><br/>You can see the html-ified docs for the latest release online:<br/><br/> http://www.openinteract.org/docs/oi2/<br/><br/>&gt; 8. OO design and implementation.<br/><br/>Yes.<br/><br/>&gt; 9. Ability to sub-class to modify functionality.<br/><br/>Most pieces of the system can be swapped out at deploy-time and <br/>run-time.<br/><br/>&gt; 10. Ability to create and easily add/ remove/ manage/ monitor plug-ins<br/>&gt; to add functionality.<br/><br/>OI (1.x and 2.x) has distributable application packages. Each package <br/>has its own database structures and initial data (and initial security <br/>settings) plus code, configuration files and localization messages. And <br/>each one is installable/upgradeable/removably by itself.<br/><br/>&gt; 11. Built-in functionality: user accounts, groups, privilege levels,<br/>&gt; home pages/ sub-sites, storage management (quotas), search,<br/>&gt; friendly/short URL&#39;s, search engine friendly/compatible.<br/><br/>Users, groups, privileges, search: yes.<br/><br/>Friendly/short URLs: sorta -- most use query strings to indicate <br/>parameters, but I think the next beta will have support for:<br/><br/> /MyApp/action/display/1586<br/><br/>instead of:<br/><br/> /MyApp/action/display?object_id=1586<br/><br/>Home pages, quotas: no.<br/><br/>Subsites: no ( I think).<br/><br/>&gt; 12. Plug-in functionality: threaded forums, issue tracking/ticketing<br/>&gt; system, CVS client, photo gallery.<br/><br/>Forums: Comes with a basic commenting system (attach comments to any <br/>object).<br/><br/>Everything else: it&#39;s not PHP Nuke. There&#39;s not much of a community to <br/>share these because OI tends to be used for internal applications. I <br/>know the Dicole folks (http://www.dicole.com/) use OpenInteract2 as a <br/>core part of their main product and have a number of community-type <br/>features available.<br/><br/>&gt; 13. Version control and content management system capabilities.<br/><br/>Not built-in.<br/><br/>&gt; 14. Information architecture hooks.<br/><br/>Not exactly sure what this means. Many interesting parts of the system <br/>can throw events and objects can register to listen for those events <br/>and react accordingly.<br/><br/>&gt; 15. Off-line and on-line development/debugging/test environments for<br/>&gt; coders and designers.<br/><br/>Not yet. You can run OI2 in a &#39;standalone&#39; environment -- not using a <br/>web server at all, submitting requests programmatically -- but it&#39;s not <br/>used very often yet.<br/><br/>You can use the same application packages and configuration from <br/>different environments. So running a standalone LWP server and under <br/>mod_perl only requires changes to their respective configuration files <br/>(e.g., apache.conf), nothing else.<br/><br/>Debugging support is pretty good because we&#39;re using the log4perl <br/>package. So it&#39;s simple to modify system-wide logging or to confine <br/>debugging levels for individual areas.<br/><br/>&gt; 16. On-line WSIWYG development environment and workflow for<br/>&gt; authors/editors.<br/><br/>Not built-in.<br/><br/>&gt; 17. On-line WSIWYG development/debugging environment for novice users <br/>&gt; to<br/>&gt; create simplified/restricted code, presentation, and/or content.<br/><br/>Not built-in.<br/><br/>&gt; 18. Comprehensive regression test suite for framework and anything<br/>&gt; distributed/supported with it.<br/><br/>Test suite: yes; comprehensive: not yet. In particular, application <br/>packages don&#39;t have testing support yet.<br/><br/>&gt; 19. Ability to run on well-featured shared Linux web hosting accounts.<br/><br/>It does work with a plain CGI interface, but I wouldn&#39;t recommend it. <br/>Anything with all these features takes some horsepower, otherwise <br/>you&#39;re building up and tearing down a lot of information with every <br/>request.<br/><br/>&gt; 20. Ability to backup and restore while operational.<br/><br/>Probably. I haven&#39;t tried it, but I guess it depends on your database. <br/>We can store sessions to the filesystem rather than the database and <br/>can do some caching of commonly used objects there (user, groups, <br/>etc.).<br/><br/>Good luck!<br/><br/>Chris<br/><br/>--<br/>Chris Winters<br/>Creating enterprise-capable snack systems since 1988<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1317.html Tue, 07 Dec 2004 22:42:32 +0000 Re: PHP is the scourge by Perrin Harkins On Tue, 2004-12-07 at 10:13 -0600, Dave Rolsky wrote:<br/>&gt; I&#39;ve never written an app for a client that started on one backend and <br/>&gt; moved to another.<br/><br/>I have. I helped move an app from MySQL to Oracle once. It took a lot<br/>of work to get rid of mysql-isms, but the DBI code itself hardly changed<br/>at all. I would agree with the earlier poster that the level of<br/>abstraction DBI provides is really helpful when this sort of thing comes<br/>along. I suspect Pear::DB is fine for this too. <br/><br/>- Perrin<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1316.html Tue, 07 Dec 2004 19:46:25 +0000 Re: Perl Framework Licensing, was: The P5EE dream is alive, was:ping... by Christopher Hicks On Tue, 7 Dec 2004, Dave Rolsky wrote:<br/>&gt; But note that the standard Perl license is not GPL-only, it is GPL|Artistic.<br/><br/>And many/most Perl modules follow this lead.<br/><br/>-- <br/>&lt;/chris&gt;<br/><br/>&quot;Fans of Mozilla&#39;s free, open-source Firefox browser make the<br/>ardent Apple faithful look like a bunch of slackers.&quot;<br/>- Rebecca Lieb at clickz.com<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1315.html Tue, 07 Dec 2004 16:02:32 +0000 Re: Perl Framework Licensing, was: The P5EE dream is alive, was:ping... by Dave Rolsky On Tue, 7 Dec 2004, Stephen Adkins wrote:<br/><br/>&gt; The GPL affects code that is &quot;linked&quot; to it and then redistributed.<br/>&gt; The issue of &quot;linking&quot; is a gray area. I believe Larry Wall has<br/>&gt; expressed that the scripting nature of the perl language means that<br/>&gt; it is not a linked language, and the GPL on one module does not<br/>&gt; therefore transfer to applications that use it.<br/><br/>I&#39;ve asked the FSF about just this, and their opinion is that the way in <br/>which a library is loaded (linked at compile time or loaded at runtime) is <br/>not relevant.<br/><br/>So a GPL-only Perl module would make any app that uses it GPL.<br/><br/>But note that the standard Perl license is not GPL-only, it is <br/>GPL|Artistic.<br/><br/><br/>-dave<br/><br/>/*===========================<br/>VegGuide.Org<br/>Your guide to all that&#39;s veg.<br/>===========================*/<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1314.html Tue, 07 Dec 2004 14:43:51 +0000 Perl Framework Licensing, was: The P5EE dream is alive, was:ping... by Stephen Adkins Hi,<br/><br/>This is my understanding of Perl licensing:<br/><br/> Perl frameworks do not pass their GPL license to applications<br/> that are written with them. You can use any GPL&#39;ed perl framework<br/> to build a proprietary application and license it separately<br/> (non-GPL&#39;ed).<br/><br/>The GPL affects code that is &quot;linked&quot; to it and then redistributed.<br/>The issue of &quot;linking&quot; is a gray area. I believe Larry Wall has<br/>expressed that the scripting nature of the perl language means that<br/>it is not a linked language, and the GPL on one module does not<br/>therefore transfer to applications that use it.<br/><br/>Stephen<br/><br/>On Tue, 2004-12-07 at 21:17, David Christensen wrote:<br/>&gt; Let me refine this one:<br/>&gt; <br/>&gt; &gt; 5. Perl Artistic License.<br/>&gt; <br/>&gt; My wish is a license that allows both propriety and open products (e.g.<br/>&gt; the framework license doesn&#39;t compel disclosure of source code or<br/>&gt; dictate licensing terms). Since I&#39;m wishing for a Perl framework, the<br/>&gt; Perl license came to mind first. Other licenses may do.<br/>&gt; <br/>&gt; <br/><br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1313.html Tue, 07 Dec 2004 14:37:10 +0000 RE: The P5EE dream is alive, was: ping... by David Christensen Let me refine this one:<br/><br/>&gt; 5. Perl Artistic License.<br/><br/>My wish is a license that allows both propriety and open products (e.g.<br/>the framework license doesn&#39;t compel disclosure of source code or<br/>dictate licensing terms). Since I&#39;m wishing for a Perl framework, the<br/>Perl license came to mind first. Other licenses may do.<br/><br/><br/>A couple of people have asked me to clarify:<br/><br/>&gt; 14. Information architecture hooks.<br/><br/>I guess what I&#39;m wishing for is support for the stuff described in the<br/>Information Architecture book<br/>(http://www.oreilly.com/catalog/infotecture2/). It&#39;s been a while since<br/>I read it, but the ideas that come to mind include content tagging and<br/>controlled vocabularies, and the ability to organize the same content<br/>into one or more navigation systems.<br/><br/><br/>Let me add one:<br/><br/>21. If it&#39;s a commercial product, the license and revenue model needs to<br/>be such that people can use the framework and applications built with it<br/>without being required to pay fees or disclose anything. Any<br/>restrictions must be minimal (e.g. display a copyright notice and<br/>disclaimer). However, the availability of paid products and services is<br/>desirable, for those who can afford it (books, training, development,<br/>support, etc.).<br/><br/><br/>Any more comments/ experiences for WebGUI?<br/><br/><br/>David<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1312.html Tue, 07 Dec 2004 13:17:35 +0000 Re: PHP is the scourge by Rob Nagler Dave Rolsky writes:<br/>&gt; I&#39;ve never written an app for a client that started on one backend and <br/>&gt; moved to another. I imagine that if this were to happen, it&#39;d be because <br/>&gt; the new backend provided some set of features that were now important to <br/>&gt; the app, and some code changes would be necessary to take advantage of <br/>&gt; this.<br/><br/>We start all projects on Postgres. When Postgres runs out of steam,<br/>we move to Oracle. This has happened once, and is likely to happen<br/>again.<br/><br/>Rob<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1311.html Tue, 07 Dec 2004 12:10:02 +0000 Re: PHP is the scourge by Dave Rolsky On Tue, 7 Dec 2004, Richard Dice wrote:<br/><br/>&gt; Dave,<br/>&gt;<br/>&gt;&gt; I think it does an ok job, but that&#39;s not really it&#39;s goal. I also don&#39;t <br/>&gt;&gt; think this is super important. You pick a particular DBMS because you <br/>&gt;&gt; think it&#39;s the right tool for the job. Only in a few rare cases (apps <br/>&gt;&gt; written for wide distribution) is there any reason to consider portability <br/>&gt;&gt; across DBMS backends.<br/>&gt;<br/>&gt; Good point.<br/>&gt;<br/>&gt; From a framework author&#39;s point of view, the framework should be able to work <br/>&gt; with whatever database the app developer deems to be the correct one for <br/>&gt; their situation. (I believe this is just the logical extension to what you <br/>&gt; were saying.)<br/><br/>Yep, pretty much. So-called &quot;database independence&quot; is something sought <br/>our by people who don&#39;t know much about databases, IMO. If you&#39;re just <br/>treating your SQL DBMS like a filesystem or &quot;object store&quot;, you&#39;re missing <br/>out on all the power the DBMS can provide if you actually use it properly.<br/><br/><br/>-dave<br/><br/>/*===========================<br/>VegGuide.Org<br/>Your guide to all that&#39;s veg.<br/>===========================*/<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1310.html Tue, 07 Dec 2004 11:42:21 +0000 Re: The P5EE dream is alive, was: ping... by Michael A Nachbaur On December 6, 2004 03:44 pm, Christopher Hicks wrote:<br/>&gt; On Mon, 6 Dec 2004, Pinda Ndaki wrote:<br/>&gt; &gt; You may want to try Maypole from http://maypole.perl.org It&#39;s a very<br/>&gt; &gt; interesting project.<br/>&gt;<br/>&gt; And even if you don&#39;t like maypole for some reason (like it makes your<br/>&gt; life too easy or something), Class::DBI which it is based on is very cool<br/>&gt; too.<br/><br/>I too am using Class::DBI, however I&#39;m integrating it in with webapps, as well <br/>as Mozilla+XUL interfaces, using SAWA and AxKit.<br/><br/>SAWA is an exciting event framework for web applications, that makes you slap <br/>your head and think &quot;Why didn&#39;t I do this before?&quot;<br/><br/>AxKit is an XSLT application server that can be used for many things from <br/>translating XML documents to HTML/DocBook, etc, or integrating various <br/>dynamic-XML generating modules into a unified web-app.<br/><br/>I&#39;m working on several projects right now using the above combination, and <br/>find it works quite well.<br/><br/>-- <br/>Michael A. Nachbaur &lt;mike@nachbaur.com&gt;<br/>http://nachbaur.com/pgpkey.asc<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1309.html Tue, 07 Dec 2004 09:58:16 +0000 Re: PHP is the scourge by Richard Dice Dave,<br/><br/>&gt; I think it does an ok job, but that&#39;s not really it&#39;s goal. I also <br/>&gt; don&#39;t think this is super important. You pick a particular DBMS because <br/>&gt; you think it&#39;s the right tool for the job. Only in a few rare cases <br/>&gt; (apps written for wide distribution) is there any reason to consider <br/>&gt; portability across DBMS backends.<br/><br/>Good point.<br/><br/> From a framework author&#39;s point of view, the framework should be able <br/>to work with whatever database the app developer deems to be the correct <br/>one for their situation. (I believe this is just the logical extension <br/>to what you were saying.)<br/><br/>Cheers,<br/>Richard<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1308.html Tue, 07 Dec 2004 09:11:10 +0000 Re: PHP is the scourge by Christopher Hicks On Tue, 7 Dec 2004, Dave Rolsky wrote:<br/>&gt; I think it does an ok job, but that&#39;s not really it&#39;s goal.<br/><br/>True enough.<br/><br/>&gt; I also don&#39;t think this is super important.<br/><br/>Agreed.<br/><br/>&gt; You pick a particular DBMS because you think it&#39;s the right tool for the <br/>&gt; job.<br/><br/>Or you&#39;ve got one database you use for everything regardless of whether <br/>its the right one or not.<br/><br/>&gt; Only in a few rare cases (apps written for wide distribution) is there <br/>&gt; any reason to consider portability across DBMS backends.<br/><br/>Given that I&#39;d like to see Perl extend its lead in terms of awesomeness in <br/>all things the rare case fo wide distribution is important to me. I&#39;m a <br/>bugzilla helper/hanger-on and folks ask about PostgreSQL and Sybase ports <br/>all the time. It&#39;d be nice if it &quot;just worked&quot;.<br/><br/>&gt; I&#39;ve never written an app for a client that started on one backend and <br/>&gt; moved to another.<br/><br/>Less than 10% of my clients have ever specified what the database backend <br/>need to be, but we&#39;ve recently had a client that has decided to move from <br/>MySQL to PostgreSQL so we&#39;ve been having to port SQL for the first time in <br/>ages. People whine about MySQL&#39;s lack of features, but in terms of <br/>available SQL syntax its a lot easier-going and handier than PostgreSQL.<br/><br/>&gt; I imagine that if this were to happen, it&#39;d be because the new backend <br/>&gt; provided some set of features that were now important to the app, and <br/>&gt; some code changes would be necessary to take advantage of this.<br/><br/>Or the priests of IT get bored and decide to change directions. In this <br/>case its a large government agency creating useless policy where the <br/>defacto was perfectly fine. Beaurocrats can s~&amp;k my left n*t. :) The <br/>same folks want to rewrite all the Perl in the whole org into PHP. It <br/>doesn&#39;t seem to have dawned on them that this is physically impossible <br/>considering some of the things Perl is doing, but I&#39;m sure they&#39;ll unleash <br/>a large enough horde to overcome it. Sadly.<br/><br/>-- <br/>&lt;/chris&gt;<br/><br/>&quot;Fans of Mozilla&#39;s free, open-source Firefox browser make the<br/>ardent Apple faithful look like a bunch of slackers.&quot;<br/>- Rebecca Lieb at clickz.com<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1307.html Tue, 07 Dec 2004 08:30:38 +0000 Re: PHP is the scourge by Dave Rolsky On Tue, 7 Dec 2004, Christopher Hicks wrote:<br/><br/>&gt;&gt; From my experience, switching databases from one to another in PHP when <br/>&gt;&gt; using Pear::DB isn&#39;t any more difficult than if I were using DBI or JDBC <br/>&gt;&gt; because the hard part in switching Databases is always in the &quot;native&quot; <br/>&gt;&gt; database code.<br/>&gt;<br/>&gt; Alzabo seems to do a good job of dealing with these things if database <br/>&gt; portability is a big deal for the project. I&#39;ve considered using it for <br/>&gt; managing database changes over time, but keeping a history of the alter <br/>&gt; tables and create tables works for now.<br/><br/>I think it does an ok job, but that&#39;s not really it&#39;s goal. I also don&#39;t <br/>think this is super important. You pick a particular DBMS because you <br/>think it&#39;s the right tool for the job. Only in a few rare cases (apps <br/>written for wide distribution) is there any reason to consider portability <br/>across DBMS backends.<br/><br/>I&#39;ve never written an app for a client that started on one backend and <br/>moved to another. I imagine that if this were to happen, it&#39;d be because <br/>the new backend provided some set of features that were now important to <br/>the app, and some code changes would be necessary to take advantage of <br/>this.<br/><br/><br/>-dave<br/><br/>/*===========================<br/>VegGuide.Org<br/>Your guide to all that&#39;s veg.<br/>===========================*/<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1306.html Tue, 07 Dec 2004 08:13:48 +0000 Re: PHP is the scourge by Christopher Hicks On Mon, 6 Dec 2004, Pinda Ndaki wrote:<br/>&gt; with all due respect to all lets please leave the flame wars for slashdot.<br/><br/>I&#39;m not looking for a flame war, but an open friendly discussion of <br/>development options would be good.<br/><br/>&gt; That being said, I think Perl is an incredibly flexible tool, capable of <br/>&gt; doing almost anything.<br/><br/>Almost? Bah.<br/><br/>&gt; You&#39;re right, CPAN is an incredible resource etc, etc etc.<br/><br/>OK.<br/><br/>&gt; However, PHP also has a tremendous amount of utility and is a powerful <br/>&gt; tool in its own right.<br/><br/>Might doesn&#39;t make right (referring to your &quot;powerful&quot;).<br/><br/>&gt; PHP5 has taken PHP to a new level.<br/><br/>Its difficult for me to translate this as &quot;we swept a few more nasty <br/>things under a new carpet&quot;, but I&#39;m sure you&#39;ll tell me something <br/>substantive...<br/><br/>&gt; If you&#39;re open,<br/><br/>Oh yes.<br/><br/>&gt; here&#39;s my 2 cents on why you might consider PHP<br/><br/>Now to the meat.<br/><br/>&gt; The Object oriented features have been really dramatically improved if you&#39;re <br/>&gt; in to that sort of thing<br/><br/>We like OOP, but for webapps OOPness doesn&#39;t tend to be critical.<br/><br/>&gt; Access modifiers, interfaces and inheritance work really well..<br/><br/>Do you have any code examples or URL&#39;s that would explain what this is and <br/>why it makes a difference.<br/><br/>&gt; The database access pieces have always been a wart, but Pear::DB was and <br/>&gt; is a big step in the right direction, it&#39;s no DBI, but its serviceable.<br/><br/>A smaller wart is still a wart, but its good this is finally moving in the <br/>right direction.<br/><br/>&gt; From my experience, switching databases from one to another in PHP when <br/>&gt; using Pear::DB isn&#39;t any more difficult than if I were using DBI or JDBC <br/>&gt; because the hard part in switching Databases is always in the &quot;native&quot; <br/>&gt; database code.<br/><br/>Alzabo seems to do a good job of dealing with these things if database <br/>portability is a big deal for the project. I&#39;ve considered using it for <br/>managing database changes over time, but keeping a history of the alter <br/>tables and create tables works for now.<br/><br/>&gt; The selects and inserts tend to transfer pretty readily, it&#39;s the <br/>&gt; procedures,triggeres and functions that can kill you.<br/><br/>Avoiding procedures, triggers, and functions is half the battle.<br/><br/>&gt; PHP is also now a JSR and will most likely be included in a future version of <br/>&gt; the Java J2EE specification as an official scripting environment in J2EE.<br/><br/>This doesn&#39;t make much difference to us. We do Java work if a client asks <br/>for it, but mercifully few do.<br/><br/>&gt; PHP is also an important tool because it&#39;s very easy to get it up and <br/>&gt; running and doing your job, and it behaves very similarly on Windows and <br/>&gt; *nix.<br/><br/>As does Apache::ASP, but to me for something to be an important tool it <br/>doesn&#39;t just need to be portable and easy to install it needs to be fun to <br/>program in. PHP doesn&#39;t do that for me.<br/><br/>&gt; PHP is a &quot;just works&quot; tool for Web applications.<br/><br/>Hardly. I&#39;ve spent way too much time fixing broken PHP. I&#39;ve seen bad <br/>code written in numerous languages, but PHP seems to encourage bad code as <br/>much as BASIC or COBOL. OsCommerce is one of the finer examples of PHP in <br/>my opinion (and a few others), but when you dig into the code its filled <br/>with the same sort of lack of flexibility and forethought that make me <br/>want to chop wood. Try installing a half dozen &quot;plug-ins&quot; and then <br/>upgrade. Even with a good version control system its a huge amount of <br/>hand work. As much as I like of OsCommerce the warts are so huge and <br/>painful that I&#39;d rather write something from scratch than try to tweak it <br/>into shape again.<br/><br/>&gt; In that narrow context, I honestly believe it&#39;s the best thing going bar <br/>&gt; none.<br/><br/>Have you ever looked at Apache::ASP? I feel the same way about it. It <br/>has the nice style of mixing HTML with code. It works easily on Linux or <br/>Windows. It includes a good quanity of built-in functionality so its <br/>&quot;just there&quot; like in PHP, but it doesn&#39;t become the vast bag of functions <br/>that epitomizes PHP. And when install new modules you can access it <br/>without recompiling anything.<br/><br/>&gt; It&#39;s got all the bases covered: Easy Session handling.<br/><br/>Apache::ASP has that built-in.<br/><br/>&gt; Strong WYSIWYG tools.<br/><br/>I don&#39;t care, but I&#39;m sure there are plenty of ASP GUI tools that work. <br/>vim is WYSIWYG enough for me.<br/><br/>&gt; Strong templating engine (a tool called Smarty. It&#39;s not TT2, but it&#39;s <br/>&gt; a strong tool nonetheless).<br/><br/>This makes no sense. When the language itself is supposed to be doing <br/>templating why would you need another templating engine on top of it? <br/>Apache::ASP allows you to define your own HTML tags. We use this in two <br/>cases a lot. (1) Every page is enclose in &lt;PAGE&gt; tags that invokes a Perl <br/>function that selects which template to use and makes sure everything the <br/>templates need is provided. This means that each page is not weighed down <br/>with any of the layout. The results are quite clean. The templates that <br/>get substituted by the perl function can be (and in our case are) written <br/>in Apache::ASP well. So things like custom menus can be implemented in <br/>code in one place and maintained in one place. If you want to make a menu <br/>that highlight the page its own you can easily do so without needing to <br/>include it on every page. And if its in one place its obviously easier to <br/>maintain. This whole method is also superior to including seperate <br/>headers and footers such as is commonly seen in TT2 development because <br/>the overall template is valid HTML and can go through GUI tools and be <br/>validated.<br/><br/>&gt; Abundant hosting support.<br/><br/>Hosting is a fine example that choice and competition don&#39;t necessarily <br/>lead to much of anything good. The percentage of competent hosters is <br/>considerably above the percentage of competent ISP&#39;s, but that&#39;s not <br/>saying a whole lot considering that the percentage of competent ISP&#39;s is <br/>infinitessimal. Its not just all the Saturday afternoons I&#39;ve spent <br/>helping our customers learn how to do what we do that I know my <br/>competitors don&#39;t do, but having had to battle with a variety of folks to <br/>get things configured properly makes me feel like the Internet is going to <br/>be the next user car lot in the minds of many consumers.<br/><br/>As this applies to PHP there are three problems:<br/><br/>(1) php.conf has to be different for different apps.<br/><br/>(2) PHP has to be recompiled to add things to it. (I&#39;ve been told this <br/>has improved, but it didn&#39;t sound like it was anywhere near as easy as <br/>CPAN.)<br/><br/>(3) Different versions of PHP can&#39;t be mixed in the same apache. We use <br/>different versions of modules all the time so that development, test, and <br/>production code can coexist within the same server.<br/><br/>&gt; Extremely high productivity for both small and large applications.<br/><br/>I understand why you say this, but given the &quot;dirty little issues&quot; its <br/>hard for me buy that. I feel that Apache::ASP lives up to this promise <br/>much better than PHP.<br/><br/>&gt; Low resource thirst (You don&#39;t need big iron to get it to perform).<br/><br/>This is also true of Perl. In fact mod_perl allows for a wider variety of <br/>efficiency tweaks than PHP has.<br/><br/>&gt; Extremely easy to setup.<br/><br/>Setup is much less important than maintenance.<br/><br/>&gt; Extremely easy to learn.<br/><br/>Given the resulting code that&#39;s out there is this really a good thing. <br/>How about &quot;not hard to learn and the resulting code isn&#39;t embarassing&quot;? <br/>That seems a lot better.<br/><br/>&gt; Easy to extend.<br/><br/>Not in my experience.<br/><br/>&gt; Other languages don&#39;t have to suck in order for Perl to appear good.<br/><br/>I agree. My criticisms of PHP aren&#39;t based on being a Perl fanatic even <br/>if I am a Perl fanatic. My criticisms of PHP come from repeated <br/>experiences that have been awful. My first PHP experience was eight or so <br/>years ago when I tried to write something in PHP/FI. I had code that when <br/>split into two files would compile fine, but when it was put into one file <br/>it wouldn&#39;t. This sort of ill conception and failure to scale has <br/>improved gradually, but it still has a long history of ill conception. <br/>Making a &quot;lite Perl that only does web&quot; was a bad idea to start with and <br/>its still a bad idea.<br/><br/>&gt; Every language has warts, that&#39;s part of their charm and why we love the <br/>&gt; ones we do and hate the ones we don&#39;t.<br/><br/>But when the masses of humanity are choosing to work in a leper of <br/>languages it causes dismay and a lot of code that needs to be refactored <br/>via the circular file.<br/><br/>&gt; I&#39;ve found that I tend to stick to languages and tools whose warts are <br/>&gt; in places that piss me off the least.<br/><br/>Absolutely. A language that works without pain in every context other <br/>than systems programming is the sort of thing I like to stick with.<br/><br/>&gt; It&#39;s all context sensitive.<br/><br/>Relativism won&#39;t get you anywhere with me.<br/><br/>&gt; Can Perl do everything that PHP can ? Yes.<br/><br/>Can PHP do a tenth of what Perl can? no.<br/><br/>&gt; Is Perl a better tool than PHP ? Depends on the context.<br/><br/>I don&#39;t see a context for PHP, particuarly given the repeated poor choices <br/>the designers have made.<br/><br/>&gt; Depending on our need, every language has issues.<br/><br/>Every language is usabe in some sense, but that doesn&#39;t mean that every <br/>language should be used for real code that is used in production.<br/><br/>&gt; Just a thought.<br/><br/>Thanks for giving me an opportunity to vent my PHP frustrations. :)<br/><br/>-- <br/>&lt;/chris&gt;<br/><br/>&quot;Fans of Mozilla&#39;s free, open-source Firefox browser make the<br/>ardent Apple faithful look like a bunch of slackers.&quot;<br/>- Rebecca Lieb at clickz.com<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1305.html Mon, 06 Dec 2004 23:59:54 +0000 Re: FW: The P5EE dream is alive, was: ping... by Rob Nagler David Christensen writes:<br/>&gt; Richard Dice wrote:<br/>&gt; &gt; What kind of features are you looking for in such a framework?<br/>&gt; <br/>&gt; Tough question. I guess it really depends upon my perspective (coder)<br/>&gt; and what I&#39;m trying to build (ideally, anything that can be seen on the<br/>&gt; web now or in the future).<br/><br/>Nice list.<br/><br/>Since you were kind enough to find two bugs in the bOP petshop<br/>tonight... :-)<br/><br/>&gt; 1. On-line user/support community.<br/><br/>Bivio-bOP@yahoogroups.com is the nominal place. We haven&#39;t really<br/>announced this before. We don&#39;t &quot;sell&quot; bOP to anybody but our<br/>customers. It&#39;s free if you want to use it, and we&#39;ll support you<br/>probably, but we&#39;re not in the business of selling frameworks. We<br/>write applications, and bOP is a side effect. We license it OSS so we<br/>don&#39;t have to discuss licensing with our clients.<br/><br/>&gt; 2. Separation of function (code), presentation (templates), and content<br/>&gt; (database).<br/><br/>Yes, and you&#39;ll also want to separate out facades (skins),<br/>security, and presentation formats (pdf, html, xml, csv, etc.).<br/><br/>&gt; 3. Genuine Perl; preferably 5.8.<br/><br/>Yes. Although people have complained that it isn&#39;t Perlish. I always<br/>thought Perlish meant TIMTOWTDI, but there ya go. ;-)<br/><br/>&gt; 4. Open-source de-facto standard language(s) and tools for the<br/>&gt; framework itself and all associated infrastructure used to work on it<br/>&gt; and the products built with it.<br/><br/>Pure Perl. The template language is Perl, too, unlike other template<br/>systems. Although, you don&#39;t need to use our template language.<br/><br/>&gt; 5. Perl Artistic License.<br/><br/>LGPL. Perl Artistic License is badly written.<br/><br/>&gt; 6. Strong security.<br/><br/>All requests (Tasks, really) are validated by the user&#39;s role in the<br/>current realm and what permissions the task requires and what<br/>permissions the role has been granted in the current realm. Models<br/>have &quot;auth gateways&quot; that force the current realm onto the query. Can<br/>be easily circumvented, but you have to do so explicitly -- which you<br/>can do anyway with poorly written code, but we make it easy to do with<br/>clearly-identified verbs like unauth_load.<br/><br/>&gt; 7. Documentation -- architecture, design, implementation, test,<br/>&gt; programmer&#39;s guide, designer&#39;s guide, author/editor&#39;s guide,<br/>&gt; administrator&#39;s manual, etc..<br/><br/>Someone wrote a tutorial fairly recently that no one read so we<br/>haven&#39;t bothered with docs. What we rely on is clear, simple code<br/>with an example we keep up to date (most of the time ;-), and run<br/>nightly tests on.<br/><br/>http://paulgraham.com/popular.html sums up the philosophy behind<br/>bOP. My book http://www.extremeperl.org explains the process by which<br/>bOP evolves.<br/><br/>&gt; 8. OO design and implementation.<br/><br/>Yes.<br/><br/>&gt; 9. Ability to sub-class to modify functionality.<br/><br/>Yes. Moreover, classes can be &quot;delegated&quot;. For example, you might<br/>want to override our default cookie handling, but not change all the<br/>code where the cookies are referenced. You do this by adding a<br/>line to your configuration file:<br/><br/> &#39;Bivio::Agent::HTTP::Cookie&#39; =&gt; &#39;MyApp::Delegate::Cookie&#39;,<br/><br/>All calls to the Bivio::Agent::HTTP::Cookie class and its instances<br/>get routed to MyApp::Delegate::Cookie, even for methods that have not<br/>been defined in Bivio::Agent::HTTP::Cookie.<br/><br/>&gt; 10. Ability to create and easily add/ remove/ manage/ monitor plug-ins<br/>&gt; to add functionality.<br/><br/>Not sure what you mean by plug-ins. bOP indirects many entities, such<br/>as, Models, Widgets, and Views, so that you can override or add to<br/>default behavior.<br/><br/>&gt; 11. Built-in functionality: user accounts, groups, privilege levels,<br/><br/>Yes. Groups are called clubs (bOP spun out of bivio.com, a site for<br/>investment clubs).<br/><br/>&gt; home pages/ sub-sites,<br/><br/>Yes.<br/><br/>&gt; storage management (quotas),<br/><br/>We currently don&#39;t make this available, because it is tied to Oracle<br/>in bivio.com. We are looking into ways of generalizing our file<br/>storage, but we&#39;re swamped with other projects right now.<br/><br/>&gt; search,<br/><br/>Google. ;-) We relied on Oracle&#39;s Intermedia for a long time, but<br/>finally canned it recently. Now searches are blazing with Google, but<br/>we lose out on non-public searches.<br/><br/>&gt; friendly/short URL&#39;s, search engine friendly/compatible.<br/><br/>You can have any URL you like. You can have multiple URLs for a<br/>single task, which is useful for maintaining backward compatibility<br/>with old URLs.<br/><br/>&gt; 12. Plug-in functionality: threaded forums,<br/><br/>http://www.bivio.com/club_cafe is an example. This code is fairly<br/>trivial, because it reuses the builtin drilldown table functionality<br/>in bOP.<br/><br/>&gt; issue tracking/ticketing system,<br/><br/>On our wish list, but there are so many free ones.<br/><br/>&gt; CVS client,<br/><br/>Don&#39;t understand. Is pserver not good enough?<br/><br/>&gt; photo gallery.<br/><br/>Visit paintedsnapshot.com for an nice example. This site took about 3<br/>weeks of one programmer&#39;s time to launch. Most of the functionality<br/>is administrative so you can&#39;t really appreciate the complexity.<br/><br/>&gt; 13. Version control and content management system capabilities.<br/><br/>No.<br/><br/>&gt; 14. Information architecture hooks.<br/><br/>Don&#39;t understand.<br/><br/>&gt; 15. Off-line and on-line development/debugging/test environments for<br/>&gt; coders and designers.<br/><br/>Yes. Our unit test framework allows you to test a task outside of<br/>Apache. For the most part, though, you need to use apache. The<br/>acceptance test framework is easy to use.<br/><br/>&gt; 16. On-line WSIWYG development environment and workflow for<br/>&gt; authors/editors.<br/><br/>Nope, but people have used DreamWeaver to do the UI for bOP sites. We<br/>may generalize this (although the code is trivial) so that you could<br/>define easily define tags for views or view &quot;parts&quot; that DreamWeaver<br/>developers could insert and move around.<br/><br/>&gt; 17. On-line WSIWYG development/debugging environment for novice users to<br/>&gt; create simplified/restricted code, presentation, and/or content.<br/><br/>bOP is not for novice users. That&#39;s what PHP is for.<br/><br/>&gt; 18. Comprehensive regression test suite for framework and anything<br/>&gt; distributed/supported with it. <br/><br/>Yes, sort of. We are still adding unit tests for bOP.<br/><br/>&gt; 19. Ability to run on well-featured shared Linux web hosting accounts.<br/><br/>No. You can rent a standalone server for less than $100/month. Any<br/>reasonably complex application will cost orders of magnitude more<br/>money to develop, and will require a dedicated server -- if for<br/>nothing else, than for ensuring your app&#39;s security isn&#39;t in the hands<br/>of someone outside your organization.<br/><br/>&gt; 20. Ability to backup and restore while operational.<br/><br/>bOP is stateless, that is, there is no concept of a session. The<br/>framework controls the commits, which happen at the end of a task.<br/>This means the database is responsible for state management, and the<br/>state should always be consistent. All of our systems are live 7x24,<br/>and we run live exports and run remote standby databases.<br/><br/>Some things bOP provides that are not mentioned above: tracing<br/>(selectable at class and statement levels), logging, simple (perl)<br/>configuration, OR mapping, (server-side) stateless form nesting,<br/>sendmail/postfix integration (all email is processed through Apache<br/>via a gateway from sendmail/postfix), and SQL/HTML/XML/etc. type<br/>mapping.<br/><br/>Caveat: I personally don&#39;t recommend bOP any more. I think there are<br/>many useful concepts in bOP, but due to bOP&#39;s highly-refactored<br/>nature, it&#39;s extremely complicated and difficult to understand at a<br/>practical level.<br/><br/>Rob<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1304.html Mon, 06 Dec 2004 21:47:45 +0000 FW: The P5EE dream is alive, was: ping... by David Christensen Richard Dice wrote:<br/>&gt; What kind of features are you looking for in such a framework?<br/><br/>Tough question. I guess it really depends upon my perspective (coder)<br/>and what I&#39;m trying to build (ideally, anything that can be seen on the<br/>web now or in the future).<br/><br/><br/>I&#39;ll start by throwing out a rough wish-list that we can all critique<br/>and modify:<br/><br/>1. On-line user/support community.<br/><br/>2. Separation of function (code), presentation (templates), and content<br/>(database).<br/><br/>3. Genuine Perl; preferably 5.8.<br/><br/>4. Open-source de-facto standard language(s) and tools for the<br/>framework itself and all associated infrastructure used to work on it<br/>and the products built with it.<br/><br/>5. Perl Artistic License.<br/><br/>6. Strong security.<br/><br/>7. Documentation -- architecture, design, implementation, test,<br/>programmer&#39;s guide, designer&#39;s guide, author/editor&#39;s guide,<br/>administrator&#39;s manual, etc..<br/><br/>8. OO design and implementation.<br/><br/>9. Ability to sub-class to modify functionality.<br/><br/>10. Ability to create and easily add/ remove/ manage/ monitor plug-ins<br/>to add functionality.<br/><br/>11. Built-in functionality: user accounts, groups, privilege levels,<br/>home pages/ sub-sites, storage management (quotas), search,<br/>friendly/short URL&#39;s, search engine friendly/compatible.<br/><br/>12. Plug-in functionality: threaded forums, issue tracking/ticketing<br/>system, CVS client, photo gallery.<br/><br/>13. Version control and content management system capabilities.<br/><br/>14. Information architecture hooks.<br/><br/>15. Off-line and on-line development/debugging/test environments for<br/>coders and designers.<br/><br/>16. On-line WSIWYG development environment and workflow for<br/>authors/editors.<br/><br/>17. On-line WSIWYG development/debugging environment for novice users to<br/>create simplified/restricted code, presentation, and/or content.<br/><br/>18. Comprehensive regression test suite for framework and anything<br/>distributed/supported with it. <br/><br/>19. Ability to run on well-featured shared Linux web hosting accounts.<br/><br/>20. Ability to backup and restore while operational.<br/><br/><br/>David<br/><br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1303.html Mon, 06 Dec 2004 20:05:26 +0000 Re: The P5EE dream is alive, was: ping... by Christopher Hicks On Mon, 6 Dec 2004, Pinda Ndaki wrote:<br/>&gt; You may want to try Maypole from http://maypole.perl.org It&#39;s a very <br/>&gt; interesting project.<br/><br/>And even if you don&#39;t like maypole for some reason (like it makes your <br/>life too easy or something), Class::DBI which it is based on is very cool <br/>too. We use Class::DBI inside some Apache::ASP apps we&#39;ve got and the <br/>combination is very nice. I&#39;m working on taking some of the glue code <br/>we&#39;ve developed and getting it onto CPAN, but its pretty easy stuff, <br/>particularly when compared to a variety of other solutions we&#39;ve seen or <br/>tried. I looked at WebGUI a few years ago and went &quot;blah&quot;, so if its the <br/>bomb I&#39;d love to hear about how. I don&#39;t remember what made me go blah, <br/>but it turned me off enough that I never wanted to try it.<br/><br/>-- <br/>&lt;/chris&gt;<br/><br/>&quot;Fans of Mozilla&#39;s free, open-source Firefox browser make the<br/>ardent Apple faithful look like a bunch of slackers.&quot;<br/>- Rebecca Lieb at clickz.com<br/> http://www.nntp.perl.org/group/perl.p5ee/2004/12/msg1302.html Mon, 06 Dec 2004 15:44:10 +0000