[JOB WANTED] !
hiya. quick note to let folks know that i am once again available for work in the sf bay area. i'm finally all settled in san francisco and am eager to get back to the craft after several months off. my resume is located at http://www.maz.org/bcm/resume.pdf (text, html, word versions also available). thanks!
Re: Caching LDAP connections
On Fri, 8 Feb 2002, Remi Godin wrote: Is there an Apache::Net::LDAP type module that would cache LDAP connections? Something that behaves in the same manner as Apache::DBI how about ResourcePool? it includes a ResourcePool::Resource::Net::LDAP class.
Re: mod_perl version for Tomcat
On Wed, 6 Feb 2002, Brett W. McCoy wrote: Why would you need mod_perl with Tomcat? You can use Tomcat with Apache using mod_jk, and get the best of both worlds. presumably so that he doesn't have to port his cgi programs to servlets. i'm pretty sure tomcat has the capability to execute cgi programs, but that doesn't buy you the acceleration you get with mod_perl. it's probably worth the original poster's time to figure out how to get apache working with ssl so he can continue to use mod_perl. his only other realistic choice is using something like xml-rpc (or maybe even http) from tomcat to a (non-ssl) backend apache/mod_perl.
RE: mod_perl version for Tomcat
On Wed, 6 Feb 2002, Stathy G. Touloumis wrote: Hmmm, from what I've read of Tomcat it is recommended to use it in conjuction with apache and just proxy specific requests to Tomcat. that's why i recommended he spend his time getting apache working with ssl. ps: you don't proxy requests to tomcat, in the http sense; you delegate request handling to tomcat, passing it info about the request using the jk or warp protocols.
Re: New mod_perl Logo
On Wed, 30 Jan 2002, Paul Cotter wrote: Give it some other marketting name, even if it keeps its original name in places like this. didn't you people read perrin's message? do you think this is the first time this topic has been discussed? do you think it's gonna change doug's mind /this/ time? if you can't sell your customers and bosses on mod_perl because of its technological appropriateness, the name of the software is the least of your problems.
Re: kylix: rad!
On Sun, 13 Jan 2002, Daniel Aldham wrote: Slashdot and Freshmeat ran a story on the weekend about the Borland/Kylix license. Pretty draconian stuff. that's where i heard of it.
Re: kylix: rad!
On Sat, 12 Jan 2002, Perrin Harkins wrote: Well, does this product actually have any users to compete for? unknown. i figure a large established software company isn't going to spend time developing a product for a market that doesn't exist, but you never know. GUI builders usually don't work for anything but the most trivial websites that could be written in anything and do fine. consider struts, a popular java mvc framework. it defines simple interfaces for things like actions and forms. does struts (and mvc in general) work for non trivial websites? a struts-oriented rad tool could easily scan WEB-INF dirs to find action and form classes and represent them in the gui. the main purpose of the tool would be to assemble and configure those classes in order to generate a struts-config.xml file. it could also incorporate ide functionality. People seem to come to mod_perl because they need more performance or more control than they can get from CGI. I'm not sure I want to try and draw in users who can't program at all. why do you think this tool would appeal to people who can't program at all? consider the popularity of java and c++ ides. do you think it's possible that people who use those languages might switch to perl if tools like this existed to generate webapps in perl? many of us on this list have well-developed preferences for editing and debugging our code, configuring and testing our applications that are based on executing shell commands in a terminal. don't you think there are lots of well developed advocacy reasons for offering an alternative paradigm? said another way, just cos *you* don't use gui development tools to develop modperl apps doesn't mean there aren't heaps of people out there who'd love to do just that.
Re: kylix: rad!
On Mon, 14 Jan 2002, Gunther Birznieks wrote: OK, I learned mod_perl, now where are my hot chicks! :) no, no, you have to pledge the frat! I think a UI tool would help a bit, but it wouldn't necessarily solve the hard part of mod_perl which is the lack of Interpreter cleanup between invocations. PHP and ASP clear their variables at the start so it seems harder for applications to overwrite each other and cause weird subtle bugs. To some degree, the nature of mod_perl feels like it makes it harder. true, altho it can be said that persistent state is part of the nature of server programming, and whether you use a tool to generate an app or code it all by hand, you have to learn to exist according to that nature. you can certainly write php code that scopes its variables properly, uses disk- and shmem-based configuration and persistence mechanisms rather than global variables, etc. but you don't have to, cos php bends over backwards to make the world a very forgiving place. i think that best practices should be enforced by the environment. i don't think it's inconsistent to create tools that make a developer's job easier (enabling him to speed up the implementation lifecycle) and that also enforce best practices. A point to note... even though we give out free Perl and Java applications, we feel that even our own config files are large and therefore daunting for beginners so we have been doing RD to come up with a web interface to create config files for MVC based web apps. A UI is not what we want because we'd like people to go through the wizard and then be able to download a pre-packaged app. web and desktop uis are all guis, right? hell, emacs jde is an ide/gui. it shouldn't be a huge technical challenge to design an application that can have multiple types of gui layered onto it. i built my last little project exactly that way - with a web interface and a command line interface. mvc helped immensely with that. I Think making things easier is always a noble effort but it's not always clear until you try, what is truly easier. 1 size doesn't usually fit all. Many peple like IDEs, many people hate them... yah. i don't really feel very comfortable in them myself. i wasn't suggesting that i was going to build this tool myself; i just thought i'd share the idea. because given the number of gui tools that exist, and the testimony of users, it's clear that at last some people find those tools useful. subject line aside, the idea/opinion that really got me in this thread was mod_perl is not for less/non experienced programmers. that may be the reality today, but it doesn't have to be by nature. it's like we were talking about on #modperl yesterday. somebody wondered why php applications tend to sport prettier/cleaner/better ui's than perl applications. i think it's cos the php community is more design oriented, specifically because the environment is so conducive to less experienced programmers getting stuff done. if you were a designer sitting down to do your first application, which would you choose - php or perl+mason/tt/whatever? you can go to php.net and see a comprehensive searchable manual of all core apis. you don't have to install anything to be able to send an email or connect to a database. you don't have to look at many web sites - just one (maybe two, if you consult phpbuilder for tips and tricks). you can store data in a web session with 2 function calls. you can reasonably make a dynamic page within 30 seconds of your admin telling you that php is installed in the web server. contrast that with what's available for mod_perl, mason, tt, etc. all well documented, but at a lower level technically. you have to ask your admin to install DBI and MIME-tools (or figure out how to install them into your home dir). you have to figure out how to cause registry scripts or mason pages to be executed (and you have to install mason). you have to write wrapper code to rig up a session framework (and you have to install session modules). etc. the bar is higher for mod_perl and friends. you have to read and understand many more concepts in order to make a hello world web page. you can't be a 9th level designer/1st level coder.
kylix: rad!
have you folks seen kylix? http://www.borland.com/kylix/ check out this white paper that describes how to create cgis and modules for apache: http://www.borland.com/kylix/papers/apache_development.pdf kylix looks pretty much like ye olde application framework, just like what many of us have built in the past, plus a gui that allows boneheads to drag and drop application components and right click to configure the application's properties, resulting in an immediately deployable cgi or dso (rad, or rapid application development). competition with this product (which has some really freaking license clauses which you can read about on freshmeat) seems pretty easy: 1) create a suite of standard web components (such as emailform); 2) build a gui to let you easily assemble and configure those components (and your custom components) into an application; and 3) provide a compiler tool that creates the cgi executable or module dso given the inputs from #2. the kylix netclx layer, defining actions (which are dispatched according to the value of the path info) and page producers (which generate html forms), is your standard mvc design. no real innovation there, we have several to choose from on cpan and in our own cvs repositories. one question is: what frameworks and components to use (task #1). you could limit the tool to one framework, say mason, or you could support an abstraction layer (libservlet comes to mind :) which would allow you to select mason or tt or axkit as you prefer. anybody interested?
Re: [ANNOUNCE] Apache::AppCluster 0.2
On Wed, 9 Jan 2002, Mark Maunder wrote: The difference is that AppCluster allows you to call multiple remote methods on the server (or on multiple distributed servers) simultaneously. However, I wasn't aware of PlRPC and I really like the interface i.e. the way it creates a copy of the remote object locally and allows you to call methods on it as if it were just another object. would it require too much surgery and api change if you added the concurrency support to PlRPC?
Re: [ANNOUNCE] Apache::AppCluster 0.2
On Wed, 9 Jan 2002, Mark Maunder wrote: Well, I guess two methods could be added to the client object. One to add a concurrent request to be called (register_request()) and one to send all registered requests concurrently. I'm not the author though, so you'll have to chat to Jochen about that. couldn't you just subclass RPC::PlClient? The server and transport would have to be rewritten pretty much from scratch I think. The transport needs to be HTTP POST requests and responses. The server needs to be set up as a mod_perl handler that takes advantage of everything mod_perl has to offer. why needs? i'm sure lots of people would rather run a very lightweight non-http/apache-based server. I dont really mind whether we incorporate this stuff into PlClient or AppCluster or both, but I do think that both the concurrency in AppCluster and tied object API in PlRPC are really useful and would be even better with the remote app server being mod_perl. seems like the ideal api gives you the best functionality from both original apis and abstracts away the choice of transport and server. An idea might be to incorporate both the AppCluster concurrency and PlRPC style api into an Apache::* module that gives us the best of both worlds with mod_perl performance (etc.) on the server side. (and then get rid of AppCluster since it will be redundant) perhaps i misunderstand, but you're suggesting making the client an Apache module? why? i like the idea of being able to write client code that uses the same rpc api no matter whether i choose to use soap, xml-rpc, a more specific http post, plrpc's transport (whatever that might be), or whatever as the transport. not all of the drivers would have to support the same feature set (i think your mechanism supports arbitrarily deep data structures?). that rpc api is one of the things p5ee is looking for, i believe.
Re: irc
On Wed, 26 Dec 2001, Philippe M. Chiasson wrote: I am usually on rhizomatic, and #mod_perl sounds pretty good to me. there's folks on both #mod_perl and #modperl. let's drop #mod_perl, cos the other is easier to type. who runs rhizomatic? do they have a standard channel registration process? can somebody in the know make that all happen? sweet!
Re: [ANNOUNCE] Apache::Singleton 0.03
On Sat, 22 Dec 2001, Tatsuhiko Miyagawa wrote: Note that multiple process cannot share blessed reference without serialization, so *One instance for one server* is just an idea. What it means is, one instance for one process, and multiple instances with shared data across one server. See t/05_server.t in this module distribution for what it exactly means. hmm.. it looks like for the server-scoped singleton, the process-cached version will be returned by _get_instance even if the shared-memory-cached version was modified by another process since the last time _set_instance was called in the first process. is this really what you want?
transient object data
doesn't it seem like there should be a way to denote object data as transient so that it doesn't get serialized by Storable, etc? i've solved this problem in the past by writing a class-specific serialization method that undefs things i don't want serialized. but it seems like something that the core should support, especially since there are so many serialization mechanisms available. thoughts?
irc
i can't believe i never thought to ask this in 4 years, but: do any of you hang out on irc anywhere in particular? shouldn't there be a #mod_perl somewhere, if there isn't already?
Re: transient object data
On Sat, 22 Dec 2001, brian moseley wrote: doesn't it seem like there should be a way to denote object data as transient so that it doesn't get serialized by Storable, etc? dammit, i keep deleting peoples' replies before i am able to reply to them myself. gunther's suggestion was to use multiple inheritance. would it be possible to use an attribute instead?
RE: mod_perl vs. C for high performance Apache modules
On Fri, 14 Dec 2001, Thomas Moore wrote: I spoke to the technical lead at Yahoo who said mod_perl will not scale as well as c++ when you get to their level of traffic, but for a large ecommerce site mod_perl is fine. the old memory is cheap rationalization doesn't go over very well at that scale either, eh.
Re: Apache::Registry HTTP HEAD feature fix ;-)
instead of redirecting stdout to /dev/null, how about redirecting it to a temporary buffer? that way you can calculate the size of the output and set the content length on the response. On Sun, 25 Nov 2001, Jean-Michel Hiver wrote: Hi guys, As promised I have been producing a fix for Apache::Registry. The module is called MKDoc::Registry because it will be integrated in the piece of software I'm working on, but feel free to do whatever you want with it. A slight litte issue is that I really don't understand why this module is working at all (read the code), but it's just working fine... could you please test it and tell me what's going on? PS: On my system the file is located here: /usr/lib/perl5/site_perl/5.6.0/i386-linux/MKDoc/Registry.pm Cheers,
[JOB WANTED] looking for a job!
hiya. after almost a year off for good behavior in australia, i'm moving back to the states. anybody want to hire me? :) preferred locations include the sf bay area (but not the south bay), portland, and seattle. i'd also consider vancouver and toronto, visa issues permitting. i'm looking for a full-time senior position with responsibilities equally weighted towards architecture, design and implementation, working on large, sophisticated web application projects in any industry. a bonus would be work directly related to the p5ee project, including the proposed web application specification and api. i'm also interested in non-web-related network applications and services. my resume is located at http://www.maz.org/bcm/resume.pdf. html version also available. thanks!
[ANNOUNCE] Wombat and libservlet releases
(apologies to those for whom this is a cross-post) after many months, i'm finally able to announce releases of my various servlet packages. - libservlet 0.9.2 (servlet api) http://libservlet.sourceforge.net/ - Wombat 0.7.1 (servlet container) http://wombat.sourceforge.net/ - Apache::Wombat 0.5.1 (embeds Wombat w/in Apache/mod_perl) http://wombat.sourceforge.net/apache/ these are all what you might call 'preview releases'. even if the idea of servlets gets you all hot, you probably don't want to start porting your apps just yet. but you can now fairly easily set up a mod_perl-based environment for servlet applications. it's pretty neat. docs there are installation instructions at the Apache::Wombat site. given my history with cpan and bundles and what not, i wouldn't be surprised to hear of problems. please direct them to the [EMAIL PROTECTED] list. thanks. other than what you see on the web sites, there's not really any other documentation. nothing that draws it all up in a nice package with a ribbon on top. you will have to do a little bit of thinking. but hopefully some of you will be motivated to do so. what's next === now that these initial releases exist, i'm working on a new round. currently that means writing servlet wrappers for mason, axkit and possibly other popular templating systems. i'll also be working more on spec compliance. my goal with all this is to stimulate discussion on web application standards and how webapps integrate with p5ee as it evolves. i'm not going to be a fierce advocate of servlets themselves, but i hope that many of you will experiment with the software and see for yourselves the many good ideas in the servlet spec (and learn from the mistakes).
Re: perl.apache.org / apache.perl.org
On Sun, 7 Oct 2001, Stas Bekman wrote: can you please post the URL again? thanks! http://thisishomemade.com/for/modperl/site/ like he said before, it's really just a reorganization of the available information, rather than a complete site architecture with fancy rollover navigation, huge menu bars, swooshes and swirls. what with mp2 and what not, it may be that this design's time has passed.
Re: perl.apache.org / apache.perl.org
On Sun, 7 Oct 2001, Stas Bekman wrote: We have had two new designs worked out long time ago, but one has been picked by take23.org and the other wasn't applied. (hi brian) :( sorry! i have this tendency to bite off more than i can chew. i have 10 projects and none of them will ever be finished. What I want to say, is that it's not a point of where to host the site. The point is that we need someone to do the job of re-doing and making it easy to maintain the site, to keep it nice. jim's design is still available if somebody wants to use it.
Re: [OT] What hourly rate to charge for programming?
On Wed, 10 Oct 2001, Gunther Birznieks wrote: At 05:14 PM 10/10/2001, [EMAIL PROTECTED] wrote: I'd like to know where I can get paid more than AU$10/hour (US$4.90 to US$5 per hour) for my mod_perl programming... You guys in America get $100US per hour?! My god, I'm in the wrong country... America is richer than Australia. gnudev, i don't know in what part of the country you're working, but i know several people in melbourne who are routinely getting paid au$80-100/hr for php, javascript/dhtml and ui design work. i haven't seen any perl work around, but then i haven't been looking either.
Re: [VERY OT] What hourly rate to charge for programming?
On Thu, 11 Oct 2001 [EMAIL PROTECTED] wrote: And imitation Guiness. Also Tooheys, (Four-X, rednecked Queensland favourite), Hahn, etc. Home-brew imitation guinness is still better than any of the rest. altho when it's not available i a quite happy with vb!
Re: server log oddness
was there ever a response to this message? i don't recall one, but i may have missed it. thanks. On Sat, 4 Aug 2001, brian moseley wrote: when exactly is the server log (Apache-server-log) shut down? i've registered a server cleanup handler that, among other things, tries to write some debugging messages to the server log. however, it seems that calling $slog-debug somehow silently dies; my code stops executing at the point i call that method, as if the method died, but i don't catch an exception when i wrap my code in eval. anybody seen anything like this before? bcm@hojmo:~ perl -v This is perl, v5.6.0 built for i586-linux
Re: odd behavior with Cache::Cache
On Sat, 4 Aug 2001, DeWitt Clinton wrote: Can you check the actual data contained within the object? If I understand things right, there is a chance that the data itself is indeed the same. However, the instance containing the data (in your case, an instance of Wombat::Core::Session) will be different because it is going through Storable's freeze and thaw during the persistence process. Therefore a new instance is created when you call get, but it is identical with respect to the data to the one you stored with the set. the data is definitely different. i am using a simple servlet that allows me to specify a name and value to be bound into the session. when i reload the page, however, the name and value are no longer bound into the session. also, on each request, the session's last accessed time is updated after the first get, but after the second get i see the original time, not the updated one. could this be because i'm only ever doing one set, at session creation time? since i'm using a memory cache, i didn't expect to have to call set every time i modify the cached data. also i didn't know that Storable was used underneath. why is this necessary?
Re: odd behavior with Cache::Cache
ps: i've modified my code to 1) only get once per request and 2) set at the end of each request. the net effect is that stuff works as expected. i'm reasonably happy with the current state of affairs, but... i don't like having to explicitly call set to force modifications to be written to the cache, and i'd prefer that get always return the same instance that i originally set. can these issues be considered for a future version of the interface? i see the need for the current behavior when using file-based caches, but perhaps there's a way to streamline operations for memory caches? perhaps Storable can be bypassed for memory caches? also, has there been any thought given to locking cached items? when i'm using a shared cache with multiprocess apache, the opportunity exists for multiple requests to access a single session simultaneously, which can lead to races. which i'm happy to ignore for now but would be nice to eventually prevent. On Sat, 4 Aug 2001, brian moseley wrote: On Sat, 4 Aug 2001, DeWitt Clinton wrote: Can you check the actual data contained within the object? If I understand things right, there is a chance that the data itself is indeed the same. However, the instance containing the data (in your case, an instance of Wombat::Core::Session) will be different because it is going through Storable's freeze and thaw during the persistence process. Therefore a new instance is created when you call get, but it is identical with respect to the data to the one you stored with the set. the data is definitely different. i am using a simple servlet that allows me to specify a name and value to be bound into the session. when i reload the page, however, the name and value are no longer bound into the session. also, on each request, the session's last accessed time is updated after the first get, but after the second get i see the original time, not the updated one. could this be because i'm only ever doing one set, at session creation time? since i'm using a memory cache, i didn't expect to have to call set every time i modify the cached data. also i didn't know that Storable was used underneath. why is this necessary?
Re: odd behavior with Cache::Cache
On Sat, 4 Aug 2001, DeWitt Clinton wrote: Excellent, this is the right approach. Sounds like I need to update the documentation to say that objects retrieved from the cache are not 'live,' they are clones. If you want to save modifications, remember to store them again in the cache. yeah, that would be helpful. thanks. Please see my last email on the subject, but for all intents and purposes, I'd like caches to behave consistently, but we could definitely create a special purpose live memory-based cache that does what you want. fair enough. when i get around to profiling, if this is an issue, i'll see what can be done. However, the good news is that there isn't really a race on writes. Basically, the last write wins. It is tough to really figure out (from the cache's perspective) what the appropriate behavior is in all cases. So the user should be responsible for locking if them want it. Of course, that should be done through the cache API, which I regretfully haven't added yet. ok. no hurry :) thanks for the help.
server log oddness
when exactly is the server log (Apache-server-log) shut down? i've registered a server cleanup handler that, among other things, tries to write some debugging messages to the server log. however, it seems that calling $slog-debug somehow silently dies; my code stops executing at the point i call that method, as if the method died, but i don't catch an exception when i wrap my code in eval. anybody seen anything like this before? bcm@hojmo:~ perl -v This is perl, v5.6.0 built for i586-linux
Re: dbi abstraction layer on perlmonks
for the next perl conference i'm writing a do everything abstraction layer. it will provide a do_stuff routine that will, out of the box, do your laundry and perform oral sex. scalable, robust, state of the art technology for e-businesses. On Thu, 2 Aug 2001, clayton cottingham wrote: hey guys and gals: i saw this code snippet called Simple DBI Abstraction Class thought it might be a good thing to look over http://perlmonks.org/?node_id=101631
Re: note on wombat
hey, sorry i haven't replied before now. got all caught up in work stuff when i returned from the conference. you have a very good set of basic questions. i'm going to use them as the basis for an faq :) i'm leaving tomorrow for gencon (WOO!!), but i'll be back next week, and i have the whole next month and a half free. you'll get your answers then :) On Fri, 27 Jul 2001, Jeremy Howard wrote: brian moseley wrote: for those of you who were at the presentation this morning and wanted more info on wombat - here are the urls: http://libservlet.sourceforge.net http://wombat.sourceforge.net Unfortunately I wasn't at the preso, but I've looked at the slides you've got up on your site. But... I don't get it :-( Where does this fit--it's all very new to me? Is it another templating engine? ;-) Is it a session manager? Is it solving some other problem that I haven't come across yet? In the preso you mention an IMAP layer. What is this, and how would it work? Would it provide an IMAP server, or is it an interface to an existing IMAP server? Sorry for the dumb questions--from the web site it all sounds intriguing, but it's gone straight over my head!
note on wombat
for those of you who were at the presentation this morning and wanted more info on wombat - here are the urls: http://libservlet.sourceforge.net http://wombat.sourceforge.net i'm working really hard on getting everything pulled together so you can download and run the thing. the actual distributions aren't available yet (the links on the wombat front page are dead), but they should be by the end of the weekend (once i get back from the conference and have some time to clean up some things). i'll post a msg to the modperl and wombat lists when it's all ready. oh and, thanks again for showing up and having patience :) i just can't seem to get my shit together for these presentations.. and half an hour REALLY isn't enough time to give a good overview.
libapreq build error
hiya. trying to build the latest cpan version of libapreq with perl 5.6.1 + use5005threads, apache 1.3.20, mod-perl 1.25. got this error: Request.xs: In function `upload_hook': Request.xs:230: `thr' undeclared (first use in this function) attached full script of build attempt and perl -V. any ideas? thanks! :) Script started on Tue Jul 24 09:30:22 2001 hojmo:/usr/local/dev/src/cpan/build/libapreq-0.33 # /usr/local/dev/bin/perl Make file.PL Checking if your kit is complete... Looks good Writing Makefile for libapreq mkdir ../blib mkdir ../blib/arch mkdir ../blib/arch/auto mkdir ../blib/arch/auto/libapreq Warning: -L../blib/arch/auto/libapreq changed to -L/usr/local/dev/src/cpan/build/libapreq-0.33/Request/../blib/arch/auto/libapreq Writing Makefile for Apache::Request Warning: -L../blib/arch/auto/libapreq changed to -L/usr/local/dev/src/cpan/build/libapreq-0.33/Cookie/../blib/arch/auto/libapreq Writing Makefile for Apache::Cookie Writing Makefile for libapreq hojmo:/usr/local/dev/src/cpan/build/libapreq-0.33 # make cp libapreq.pod blib/lib/libapreq.pod cp lib/Apache/libapreq.pm blib/lib/Apache/libapreq.pm make[1]: Entering directory `/usr/local/dev/src/cpan/build/libapreq-0.33/c' cc -c -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/modules/perl -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/include -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/regex -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/os/unix -I/usr/include/apache -D_REENTRANT -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\0.10\ -DXS_VERSION=\0.10\ -fpic -I/usr/local/dev/lib/perl5/5.6.1/i686-linux-thread/CORE apache_request.c cc -c -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/modules/perl -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/include -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/regex -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/os/unix -I/usr/include/apache -D_REENTRANT -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\0.10\ -DXS_VERSION=\0.10\ -fpic -I/usr/local/dev/lib/perl5/5.6.1/i686-linux-thread/CORE apache_cookie.c cc -c -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/modules/perl -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/include -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/regex -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/os/unix -I/usr/include/apache -D_REENTRANT -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\0.10\ -DXS_VERSION=\0.10\ -fpic -I/usr/local/dev/lib/perl5/5.6.1/i686-linux-thread/CORE apache_multipart_buffer.c rm -rf ../blib/arch/auto/libapreq/libapreq.a /usr/bin/ar cr ../blib/arch/auto/libapreq/libapreq.a apache_request.o apache_cookie.o apache_multipart_buffer.o : ../blib/arch/auto/libapreq/libapreq.a chmod 755 ../blib/arch/auto/libapreq/libapreq.a cp apache_cookie.h ../blib/arch/auto/libapreq/include/apache_cookie.h cp apache_multipart_buffer.h ../blib/arch/auto/libapreq/include/apache_multipart_buffer.h cp apache_request.h ../blib/arch/auto/libapreq/include/apache_request.h make[1]: Leaving directory `/usr/local/dev/src/cpan/build/libapreq-0.33/c' make[1]: Entering directory `/usr/local/dev/src/cpan/build/libapreq-0.33/Request' cp Request.pm ../blib/lib/Apache/Request.pm /usr/local/dev/bin/perl -I/usr/local/dev/lib/perl5/5.6.1/i686-linux-thread -I/usr/local/dev/lib/perl5/5.6.1 /usr/local/dev/lib/perl5/5.6.1/ExtUtils/xsubpp -typemap /usr/local/dev/lib/perl5/5.6.1/ExtUtils/typemap -typemap /usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/typemap Request.xs Request.xsc mv Request.xsc Request.c cc -c -I../c -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/modules/perl -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/include -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/regex -I/usr/local/dev/lib/perl5/site_perl/5.6.1/i686-linux-thread/auto/Apache/include/os/unix -I/usr/include/apache -D_REENTRANT -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\0.33\
Re: BOF?
On Tue, 17 Jul 2001, Ask Bjoern Hansen wrote: Sunday evening where? sounds like the hotel bar is the only real option. i'll be there 8.30-9pm i guess.
Re: BOF?
On Mon, 16 Jul 2001, Eric Cholet wrote: --On 16/07/01 16:48 +0200 Robin Berjon wrote: I arrive on Sunday evening too, is there a good way to recognize a bunch of modperlians ? I've only ever seen two people on this list so if they aren't there I won't recognize anyone :) don't worry, both these people will be there ;) heh. maybe there should be a series of mug shots on the web site.
Re: BOF?
On Sat, 14 Jul 2001, Ken Williams wrote: I just noticed that there's no mod_perl BOF listed at http://conferences.oreillynet.com/cs/os2001/pub/10/bofs.html . Is one scheduled? If not, let's get one together. speaking of which. there should be an opening night piss-up, eh? somebody that knows the area should propose a place.
Re: BOF?
On Sat, 14 Jul 2001, Richard Dice wrote: Which opening night would that be? I'm not getting in until Tuesday noon. At the same time, I'm recovering at the moment from last night's piss-up... I don't think I'll need a repeat anytime soon. Still, I'm sure the company would be fun. :-) umm, the night before the first day of tutorials. i'm sure people will be getting together every night. but it was pretty cool last year for all the mp folks to show up at one place that first night.
Re: tying STDIN/STDOUT
hmm... i think i have a similar question. i want to prevent people from writing data directly to the apache connection and instead force them to use an object i provide for generating output. they can call $obj-print() directly, but i also want them to be able to use 'print foo\n' as is standard in handlers and registry scripts. seems like i want to untie STDIN and STDOUT as per below.. but then how do i attach those handles to my object's print method? is tieing the correct approach, or is there some other kind of filehandle magic i can use? On Fri, 13 Jul 2001, Jonathan Bartlett wrote: I know this has been discussed a little before, but the Test.pm PerlHandler I've attached does not work as expected. The reason being that dup-ing a read filehandle to STDIN overwrote STDOUT instead (well, actually both, since apache apparently uses the same handle for input and output). Anyway, this actually worked in RH 6.x, but stopped working when I installed 7.1. My guess is that for whatever versions are in 6.x STDIN and STDOUT were only tied for registry scripts, but in 7.x they got tied for regular content handlers as well. Currently, I'm working around it by putting untie(*STDIN); untie(*STDOUT); at the beginning of my handler. Is that the best way to go? I tried sticking it in the initialization part of the module, but that didn't work. Why is that? Anyway, if anyone has additional questions about what I'm doing here, let me know. The example is quite contrived, but it does affect a real-world situation. The actual problem line is open(STDIN, RD), which dups RD onto filehandle 1 (STDOUT) instead of 0 (STDIN). Later, when '/bin/ls' is exec-d, when it tries to write to STDOUT, it gets EBADF because there's a read file handle there. Anyway, the script can be installed with PerlRequire Test.pm location /mytest/ SetHandler perl-script PerlHandler WRI::Test::handler /location Anyway, let me know if there is a better way of handling the situation. Jon
Re: detecting ssl
is checking for $ENV{HTTPS} not sufficient?
On Tue, 10 Jul 2001, João Pedro Gonçalves wrote:
This approach should be ok:
my $s = $r-lookup_uri($r-uri);
my $ssl = $s-subprocess_env('HTTPS');
I looked at this a while back and this is usually set internally
in apache by the ssl implementation.
João Pedro
brian moseley wrote:
warning: these may be silly questions. but i've looked
through the guide and not found the answers, so hopefully
they're not that silly.
how can i test in a content handler if the request was
received over an ssl connection? do i have to look for an
environment variable? is there a test that works with all
the various ssl modules? is there a standard ssl
interface? if so, where is it documented?
thanks!
custom config directives
is there any good thorough documentation on building custom config directives other than what's in the eagle book? i left mine back in au and i don't really want to buy another one :)
detecting ssl
warning: these may be silly questions. but i've looked through the guide and not found the answers, so hopefully they're not that silly. how can i test in a content handler if the request was received over an ssl connection? do i have to look for an environment variable? is there a test that works with all the various ssl modules? is there a standard ssl interface? if so, where is it documented? thanks!
Re: The latest templating system: PSP in DDJ
On Sun, 8 Jul 2001, Perrin Harkins wrote: Good grief! This sounds exactly like Apache::ASP with its XMLSubs feature. except with asp you get the whole asp web application environment as well.
Re: Apache::SimpleTemplate
On Sat, 7 Jul 2001 [EMAIL PROTECTED] wrote: Text::Template probably is the most similar existing package, but it is not made for mod_perl. someone well- versed in mod_perl could build a mod_perl wrapper of it fairly quickly, but they or especially someone new to mod_perl shouldn't have to. (i don't know of any such wrapper existing in CPAN...) if such a wrapper did exist, would you use it? if it doesn't, why don't you write one yourself?
Re: Apache::SimpleTemplate
On 7 Jul 2001, Randal L. Schwartz wrote: Yes. Writing a templating system in Perl is trivial. Writing a *useful* templating system in Perl is demonstratably hard. unless you keep application features in a separate layer from the templating system (eg the servlet api ;)
server tokens
is there any way to access the server tokens in mp 1.24? i'd like to use them at server startup time.
Re: server tokens
On Fri, 22 Jun 2001, Matt Sergeant wrote: On Sat, 23 Jun 2001, brian moseley wrote: is there any way to access the server tokens in mp 1.24? i'd like to use them at server startup time. You have to use XS. AxKit does it this way. I'd paste the code here but it's a bit all over the place, so you'd be easier to just download it. oh, it's not really that important, don't want to add a bunch of extra stuff to my build. thanks tho. pals: consider this a feature request for the core :)
fancy perl2html replacement
warning: these questions are completely off list topic, but i bet they're still interesting to lots of you. does anybody know if nice fancey pod2html replacements exist? specifically, i want a tool that generates framesets with package and class indexes like javadoc does. also, what's the opinion on extending pod? my method documentation currently looks like this: =head2 METHODS =over =item new() Construct and return an instance. =item setFooBar($value) Sets the value of the FooBar. BParameters: =over =item $value the value to set =back BThrows: =over =item BException::Class::Base if something goes wrong =back =back wouldn't it be nicer to have a set of compact constructs for code documentation? maybe like so: =constructor new() Construct and return an instance. =method setFooBar($value) Sets the value of the FooBar. =param $value the value to set =exception BException::Class::Base if something goes wrong would enable the fancy javadoc-like tool to easily generate constructor and method summary and detail lists and to format all that stuff in attractive and easy to read ways, rather than having big sets of lists that are semantically meaningless. i bet somebody's gonna say hey, use xml instead! but then i lose all the pod support built into tools like makemaker.
Re: [OT] Re: fancy perl2html replacement
neat! thanks for the info. On Wed, 20 Jun 2001, Stas Bekman wrote: On Tue, 19 Jun 2001, brian moseley wrote: warning: these questions are completely off list topic, but i bet they're still interesting to lots of you. You want to take these questions to a list designed especially for this purpose: [EMAIL PROTECTED] And check CPAN, there is a bunch of new packages extending pod (of course they are all discussed here). You can check the list's archive here: http:[EMAIL PROTECTED]/ _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
[JOB] looking for one
hiya. time to pimp myself out again! i'm looking for full time or contract work beginning in july. the catch of course is that i'll need to be able to telecommute from melbourne, australia at least 50-75% of the time. i have no special requirement for the remainder :) i'll be in san francisco starting the 1st of july for ~3 months, so i can be onsite anywhere in north america pretty easily during that time period. travel elsewhere is not out of the question. see http://www.maz.org/bcm/resume.txt for more details. thanks!
[ANNOUNCE] libservlet 0.9.1
The URL http://www.maz.org/libservlet/dist/libservlet-0.9.1.tar.gz has entered CPAN as file: $CPAN/authors/id/I/IX/IX/libservlet-0.9.1.tar.gz size: 79634 bytes md5: b091b143fe57bc05214ec9db6eb40d6d This is the first public version of libservlet. You can't do much with it yet, since no Perl servlet containers exist yet. However, I wanted to get some eyeballs on it, and it would be great if somebody got excited enough to volunteer help. There are a few outstanding issues and some documentation work needs to be done. 95% of the work is done tho, which means I can turn my attention back to Wombat and hopefully get a working container released in the next week or so. For more information, see http://www.maz.org/libservlet/. A mailing list has been created - mailto:[EMAIL PROTECTED]. Feedback is most certainly welcome! (blurb from web site:) The Servlet API for Perl (libservlet) is a formulation of the Java (TM) Servlet API in Perl. The current version of the API is 2.3. While the servlet concept originated with Java (TM), its component model is quite natural for Perl as well. By writing servlet applications and deploying them in a servlet container, application authors can spare themselves the effort of writing commonly needed web application infrastructure components for each new project. Furthermore, servlet applications are portable between deployment environments; they can be executed in any servlet container using any process model with only a few configuration changes and no application code changes. Servlet applications are insulated from changes in vendor or platform and are able to portably take advantage of standard web infrastructure services offered by any servlet container.
Re: Real Widgets and Template Languages
On Thu, 31 May 2001, Gunther Birznieks wrote: Let's put it this way, I have actually used widgets for the last 6 months in real world applications using JSPs and widget libraries in Java. I can't tell you what a joy it is to work with something so relatively simple and just easy to put things in a page. which widget libraries?
Re: Real Widgets and Template Languages
On Thu, 31 May 2001, Gunther Birznieks wrote: I think it can be supported through a custom subclass of what you have been describing as a container/controller for the widgets. I think if it is done at the widget level it is bloating the widget set and I honestly don't see why a widget should know about languages. depends on how granular your widgets are. if you have a menu widget that also displays a label, the widget needs to know where to place the label relative to the menu. this choice will probably differ for various languages. course you add some kind of location api to the widget, but then you're bloating again. or you can just keep labels outside widgets ;)
Re: Real Widgets and Template Languages
On Thu, 31 May 2001, Gunther Birznieks wrote: Hmmm, I don't know about memory savings. But the feature you've outlined here could be taken advantage of by widgets but I don't think it should be part of the widget library. I think it's better as a separate CPAN module for dealing with I18N in general and maybe it already exists... yeah, it's called gettext.
Re: unsubscribe remove
unsubscribe remove what goes on with all this unsubscribe remove crap i'm seeing on multiple mailing lists? is this the magic phrase for some new mlm i haven't seen yet? for god's sake people, look at the message headers: list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED]
Re: Real Widgets and Template Languages
On 25 May 2001, Chip Turner wrote:
My only objection to this (as I stated in another email)
is that it leaves things largely unspecified. It's
similar to the old perl problem of passing big hashes
around; you assume the data is there, but there's no
real way to find out without checking keys and so forth.
A simple $foo-isa('Widget::CGIData') can ensure that
what you're talking to is at least derived from the
right thing. Just because perl would let you call
methods on a class not derived from a standard base
doesn't mean it's necessarily appropriate. An abstract
base class offers little overhead (especially if you
override all of the methods) while still giving that
little bit of insurance about just what you've been
passed. In a library that conceivably could be used by
a number of people, such discipline would probably be a
nice thing, even if it didn't actually buy anything in
terms of performance or features.
so the only reason you'd provide a superclass is to be able
to do an isa check? in what circumstances do you use this
kind of check? do you apply it to every argument in every
method call? what do you do on failure?
i've been wondering how best to specify interfaces (in the
java sense) in perl, whether or not to make them classes.
possible benefits are type checking (as you've noted above)
and verification of the implementation of methods specified
by the interface. altho if i could get benefit #2, i
wouldn't care about #1, cos i just want to be sure that the
implementing class (or one of its ancestors) declares each
of the interface methods. and i want this verification at
compile time, not runtime.
Re: Appending Sessionid to all the urls
On 25 May 2001, Chip Turner wrote: The problem you mention is real, but in real world scenarios it can typically be avoided. About the only thing you can't avoid is if the user wants to log in simultaneously as two different users. Most normal users don't want to do that, though :) only if you have a one to one relationship between client (browser) session and authenticated user. this is not mandatory if, as you point out, urls or form fields are used to transmit the user's id. other than this scenario, which i've never chosen to support, i've never met a piece of session-scoped data that needed to be propagated back to the client besides the client's session id.
Re: Real Widgets and Template Languages
On 25 May 2001, Chip Turner wrote: Code is cleaner if you can say the nth parameter is derived from the base class Foo::Bar as opposed to the nth parameter is an object that must support the baz, blah, foop, and fitz methods that accept parameters in the following way... you can certainly say the nth parameter implements interface Foo::Bar, and provide Foo/Bar.pod that describes the interface, and get the exact same benefit. i question the wisdom of relying on a code-level inheritance usage to communicate class relationships. isn't that why we use class diagrams and pod?
ANNOUNCE: Soup (0.2) (fwd)
so who's doing the perl wrappers? -- Forwarded message -- Date: 22 May 2001 23:48:06 -0400 From: Alex Graveley [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: ANNOUNCE: Soup (0.2) Ximian is happy to announce the first release of Soup, a Simple Object Access Protocol (SOAP) implementation in C. About SOAP: == SOAP is a generic RPC mechanism, which uses XML for data and type encoding and is transferred over protocols such as HTTP and SMTP. It is language and operating system agnostic, and very lightweight. The immediate benefits to SOAP over other RPC mechanisms such as CORBA or COM are that it functions well through firewalls and is easily encryptable. Some of the more interesting aspects are SOAP's rich type system, built on the emerging XML Schema W3C spec, and the ability to interoperate with other RPC mechanisms. About Soup: == Soup provides a queued asynchronous callback-based mechanism for sending and servicing SOAP requests, and a WSDL (Web Service Definition Language) to C compiler which generates client stubs and server skeletons for easily calling and implementing SOAP methods. It uses the GLib main loop and is designed to work well with GTK applications. Features: * Completely Asynchronous * Connection cache * HTTP chunked transfer and persistent connections * authenticated HTTP, SOCKS4, and SOCKS5 proxy support * SSL Support using OpenSSL * Apache module server support * Client digest authentication * WSDL Compiler Availability: Download the latest tarball at: ftp://ftp.gnome.org/pub/GNOME/unstable/sources/soup/soup-0.2.tar.gz Or from GNOME CVS, in the soup module. Also, please feel free to join to the Soup discussion list. To subscribe, send mail with the word Subscribe in the message body to [EMAIL PROTECTED] To learn more about SOAP, XML Schema, or WSDL, follow: * http://www.w3.org/XML/Schema(XML Schema home) * http://www.w3.org/TR/SOAP/ (SOAP 1.1 spec) * http://msdn.microsoft.com/xml/general/wsdl.asp (WSDL 1.1 spec) * http://www.develop.com/soap/default.htm (Developmentor SOAP home) * http://msdn.microsoft.com/soap/default.asp (Microsoft SOAP home) -- make: *** No rule to make target `sense'. Stop. ___ gnome-announce-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gnome-announce-list
Re: Exception modules
On Mon, 30 Apr 2001, Jeffrey W. Baker wrote: type of exception. Right now I cannot in fact think of any program I have written that branches on the type of exception. Java encourages this with multiple catch in CP Web Mail, the underlying libraries throw typed exceptions so that the application layer can display the correct error notification to the user. for instance, if the library throws CP::InvalidMailboxNameException, Web Mail can display 'the mailbox name you suggested contains an illegal character. it must correspond to the format thus-and-such. try again.', whereas if the library throws CP::Exception (the generic exception), Web Mail will handle it as a service problem and display that godawful WM page.
Re: Exception modules
On Mon, 30 Apr 2001, Perrin Harkins wrote: I've tried that, but last time I went with more general classes of exceptions containing unique error IDs (defined in a constants module) to indicate the exact type. Not as Java-like, but it did save me from creating dozens of classes with no unique properties except their names. yeah. the only really cool thing about having separate exception classes is that they can add their own methods. sometimes that's useful. I suppose it's a matter of debate whether or not bad user input should be handled with exceptions at all, but i prefer them cos then i can have lots of methods with void return type. then i can call lots of methods in a single eval black and never have to check any return values. just a stylistic preference i guess.
Re: Can AxKit be used as a Template Engine?
On Mon, 23 Apr 2001, Matt Sergeant wrote: The alternative of course it to just plug them both together - AxKit and Mason play nicely together using Apache::Filter (though it's a bit slow). with version 2.3 of the java servlet api, you can now create input and output filters, just like the filters in apache 2.0. so your servlet can do the mason stuff and an output filter can do the cocoon stuff. i feel justified in throwing this out because i'm finally back to work on the perl servlet engine :)
[JOB] for hire
hi folks. i've recently moved to melbourne, australia, and pretty soon now i'll be looking for consulting work. i've been working at critical path for the last 3+ years. i was lead developer on the cpth webmail product for the first year, after which i joined the core architecture team whose scope included the entire messaging platform and web application suite. for the last several months i've been an architect and developer for cpth's suite of integrated collaboration apps. i've been writing sophisticated mod_perl applications for 3 years. i'm familiar with internet messaging-related protocols such as http, imap, smtp, ldap, icap and webdav. i have moderate experience with database design and programming, altho i don't claim to be an expert in maintaining or tuning database server installations. i've built your typical two-tier web/db sites as well as large business applications. i've slung guns at small shops and written heavy documents in large process-oriented engineering dept. most importantly, i think, i've got several years of experience shipping many releases of a single product, from an initial release through two re-architectures, a complete user interface redesign, internationalization and localization to 20 languages. i'm currently porting the java servlet api and tomcat servlet engine to perl. if anybody wants to pay me for that, i'd love to hear your proposal :) otherwise, i'm interested in discussing consulting arrangements for any type of perl-based project. if you're in melbourne, or if you want to work out travel, on site work is fine. telecommuting is the standard, however.
Re: [JOB] for hire
er. still running pine on a server in california; the lag is intense and caused a brainfart. anyway, my resume can be found at http://www.maz.org/~bcm/resume, altho it's simply going to go into a bit more detail about what i discussed below. i'll probably be ready to swing into action within a month, so if you've got some projects on the horizon and i look like a good fit, drop me a line at [EMAIL PROTECTED] cheers! On Sun, 21 Jan 2001, brian moseley wrote: hi folks. i've recently moved to melbourne, australia, and pretty soon now i'll be looking for consulting work. i've been working at critical path for the last 3+ years. i was lead developer on the cpth webmail product for the first year, after which i joined the core architecture team whose scope included the entire messaging platform and web application suite. for the last several months i've been an architect and developer for cpth's suite of integrated collaboration apps. i've been writing sophisticated mod_perl applications for 3 years. i'm familiar with internet messaging-related protocols such as http, imap, smtp, ldap, icap and webdav. i have moderate experience with database design and programming, altho i don't claim to be an expert in maintaining or tuning database server installations. i've built your typical two-tier web/db sites as well as large business applications. i've slung guns at small shops and written heavy documents in large process-oriented engineering dept. most importantly, i think, i've got several years of experience shipping many releases of a single product, from an initial release through two re-architectures, a complete user interface redesign, internationalization and localization to 20 languages. i'm currently porting the java servlet api and tomcat servlet engine to perl. if anybody wants to pay me for that, i'd love to hear your proposal :) otherwise, i'm interested in discussing consulting arrangements for any type of perl-based project. if you're in melbourne, or if you want to work out travel, on site work is fine. telecommuting is the standard, however.
Re: Upgrading mod_perl on production machine (again)
On Tue, 16 Jan 2001, David McCabe wrote: From: Steve Reppucci [EMAIL PROTECTED] I've always handled the support of multiple perl versions by installing new versions of perl using a prefix like /usr/local/perl/5.6.0, etc., (I also place CPAN's build directory under that tree.) That is what I do as well. Plus, I use the prefix arg to build Apache as well, so a new mod_perl/Apache gets installed in a different dir than the current one when I run make install. I then copy over my config files to the new dir, and set up the new Apache to listen on a different port, then test it. Once tested, I point the sym-links for both Apache and perl to the new locations. we go one step further and install perl and other libraries with each version of our application, into say /usr/local/webmail/5.0.0.1 or whatever. that way everything the application depends on is in the version-specific directory. we drive our entire build and install process with make; the whole process is something like this (abbreviated): cvs co Makefile.webmail make -f Makefile.webmail checkout build install rpm checkout pulls all the library and application sources from cvs and scps pre-compiled distributions from a package machine. build compiles everything. install puts it into /usr/local/webmail/version. rpm packages up the installation directory. then to deploy in production, we rpm -i on each machine, and a post-install script flips the symlink to point at the new version. rollback is trivial.
Re: Apache::LogSTDERR
no worries. i'll go put it on cpan. On Wed, 20 Dec 2000, Kees Vonk 7249 24549 wrote: Stas, I am sorry I didn't see the 'it has not been released yet' bit of your message. I read Doug's note, which says: it's in our cvs tree here at CP, not on CPAN. it shouldn't be a problem to release this one to CPAN, I'll check. but I didn't realise that CP wasn't public domain, I just couldn't find it anywhere. My apologies once more, Kees Vonk
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, martin langhoff wrote: I have this dangling idea of building a TWIG lookalike (in Perl), with a 'plug-in'/'module' structure, so I may write the email client, and others fill with their desired modules. Anyway, it's a seriuos undertaking, but it's in my plans to rip as much code and design choices from stable OS webmails as possible. (speaking as the author of a proprietary mod_perl webmail...) DO IT!! twig's the best thing out there and it's highly functional but aesthetically atrocious. i use it but i wish there was a good mod_perl alternative. i'm not terribly interested in hacking php. i don't know if i could legally help write code or not. might not be an issue at all, dunno. but i can certainly give advice.
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, martin langhoff wrote: brian moseley wrote: (speaking as the author of a proprietary mod_perl webmail...) DO IT!! my fear is that writing it as a mod_perl app, it'd be terribly niche, and we wouldn't get it rolling. I'd rather write a bunch of modules, that can be called from a CGI or a templating system. Then those modules can be reused on other apps. you'd be silly if you didn't layer your application this way. Plus, we should be writing that is pure-CGI compatible -- y'know, we won't be needing any actual mod_perl hooks, and CGI-compat means is more usable under other configs, and keeps you honest. up to you. if i was doing it i'd be using ao and mason :)
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, Perrin Harkins wrote: Is there a reason you don't want to just hack on WING? It's a pretty powerful system and it was designed for mod_perl. Look it up on CPAN. it's an option, but it's got a large amount of dependencies, which makes it a tremendous effort for me to install on my system. for instance: 'On the frontend, install PostgreSQL. You may be able to use another SQL database, but (1) it must support transactions (this rules out MySQL unless someone rewrites Wing::Login in a way which doesn't require transactions). (2) it must support using ident lookups for authentication (or else you will have to tweak the DBI connection setup).' all in all, it's a somewhat daunting task. on the other hand, you've got me itching to give it a shot :)
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, Robin Berjon wrote: Wing has been widely tested in the field iirc, it's probably a good idea to base anything in that domain on it. possibly. groupware applications aren't that complex really, tho (except for calendaring and scheduling); the main problem is that they're *large* when they become featureful, and in some ways it feels like a waste to build a new one just cos "i want to do it my way". i'd really like to see an app with a much more outlook-ish interface than twig. and i don't think wing has all of the pim functionality that twig has. can't say if wing is a good starting point for that or not.
Re: Email (mod_perl) Apache module?
On Fri, 15 Dec 2000, martin langhoff wrote: Perrin Harkins wrote: Is there a reason you don't want to just hack on WING? I've seen TWIG and its *very* clever, if ugly. It'll let you authenticate against a lot of things. Use IMAP or POP. Use News. Use mysql, Postgres, MySQL, or none. Use cookies or encoded links for state. It's *very* flexible, and I've come to like that a lot. That's why I'd like to base most of my design choices on it. yup.
Re: Article idea: mod_perl + JSP
On Thu, 14 Dec 2000, Chris Winters wrote: I think a *really* good Perl person can be faster, but that's just a gut instinct. Most of us mortals don't qualify. i used to think that, until i watched a set of really good *engineers* move quickly inside and between c++, java and perl. i no longer believe that language experts are the be all and end all. altho it is nice to have experts in particular skills - like wrapping things with xs.
Re: Article idea: mod_perl + JSP
On Thu, 14 Dec 2000, Gunther Birznieks wrote: So I guess it's a matter of degree. I simply do love Perl, but I don't hate Java, I just merely really like it. I guess you could say I cheat on my Perl gf all the time. :) But unlike in life, I don't think a monogamous relationship with my language is actually very healthy. http://www.polyamory.com/
Re: Mod_perl tutorials
On Thu, 14 Dec 2000, Robin Berjon wrote: really notice or care. Most of the content is more or less static, at least it doesn't change all that often. yah. i'm sure wml or it's like would work just as nicely for managing the site. it's just, as everybody on this list knows, a gigantic pain in the ass to apply a new look to a large, disorganized sprawl of multiply-formatted OLD documents.
Re: Mod_perl tutorials
On Thu, 14 Dec 2000, Robin Berjon wrote: I didn't mean to target you particularly there brian :) i know :) But indeed I bumped into the same problem. Back then my todo list included writing Pod::SAX and pod2sax (a pod translator that woudl generate SAX events) and an XML publishing tool, which would have taken care of turning the site into whatever layout might have been needed. Of course, in the meantime Matt came up with AxKit and something that does more or less what I wanted to do with Pod::SAX (neither take care of *all* the requirements that I set for myself, but then I didn't release anything and it's probably much better to have a good part of it than all of it :). another reason it never got off the ground is that it seemed to make a lot of sense to actually use mod_perl to serve the site, but from what i've heard, the powers that be on locus aren't interested in adding it. checkpoint: bcm@rubel:~ HEAD http://perl.apache.org 200 OK Connection: close Date: Wed, 13 Dec 2000 23:17:18 GMT Server: Apache/1.3.15-dev (Unix) tomcat/1.0 Content-Type: text/html Client-Date: Wed, 13 Dec 2000 23:19:23 GMT Client-Peer: 63.211.145.10:80 we thought about moving perl.apache.org to rubel, but we never actually got around to it. ah well. i'll reiterate a point i've made several times over the last year - it would make sense to retire perl.apache.org and build a couple new sites, one for developers and one for advocacy. take23 seems to fill the latter role well, altho i'd much rather see it named modperl.org, and the former could well benefit from being on sourceforge (if they ever fix their damn login problems, jeez).
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On 7 Dec 2000, David Hodgkinson wrote: Development are two of the bibles. I have to say though, I've avoided the Design Patterns type books purely because of the C++/Java bias. you sure are missing out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Gunther Birznieks wrote: Has anyone written a Perl IDE in Perl? i goofed around with a class browser/code generator a while back, but i lost interest. as i recall, #perl laughed at me when i suggested it :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. that's why Bundle::AO is nice. it's stubborn adherence to models like this, tho, that keeps us from making generational advances rather than incremental ones. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: I quite like the Zope model - a single distribution which just includes and installs everything you need in a single place. You get python, the httpd, the database, everything. Of course if you have more complex needs, like running Zope from within Apache, you need to do some extra work, but out of the boz Zope gives you a great system that just runs. We could do that with AxKit - just ship it with Apache, mod_perl, the whole lot. But I don't think that would appeal to Perl people somehow. Thoughts? this is how we ship our products internally at cpth. we build perl, apache, 100 or so modules, and ~150 registry scripts. then we rpm the whole thing up. the operations team just has to: rpm -i /usr/local/webmail/current/bin/wmctl start. doing something like that doesn't play nice with the os vendor distributions really, but some people might like it. another option would be to use autoconf. wrap a configure script around your entire set of components. allow it to find and use whichever ones you've already got installed. have it build and install whatever you don't already have. not very tough. also not very portable to windows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Jim Woodgate wrote: I know that you can communicate with the server in the request, it's not totally stand-alone. But I haven't looked into putting in handlers in other phases... i believe with mod_jk there is a callback model, yes. but given tomcat's valve architecture, i don't see much need to call back into apache at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: What does Bundle::AO give you that setting PREREQ_PM correctly wouldn't? i don't know :) i use them both. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matthew Kennedy wrote: ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html too bad it's windows only :/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matthew Kennedy wrote: from CPAN, then good for you. I'm sure you can in some cases. I think mod_perl has done an excellent job of conquering the the two-teir web-based problems. I love tools such as Mason and Apache::ASP which ride on mod_perl. Perl-DBI is an excellent advancement for Perl in general also. I think it's exciting to think what an n-tier framework in Perl might look like. IMHO, it should be more than just the outgrowth of CPAN's contents. i can't add anything to your statement other than emphatic "me too!" i'm glad to hear that others recognize that we have work to do and are excited about the possibilities. i wonder if there's enough excitement to think about producing some useful software! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
On Wed, 6 Dec 2000, Aaron E. Ross wrote: while the install and auto configure part is not very glamorous, the possibility of being able to untar one package to get mod_perl w/ persistent db connections, transaction management, data relational modeling/objects and a nice templating/servlet engine is very glamorous! you could be a folk hero! honestly it seems like a pretty worthwhile project to me. basically, what is missing is (cough! cough!) simply a lot of hard work. except for transaction management, which is apparently of questionable value, all the pieces exist, right? database abstraction and connection pooling = DBI session management= Apache::Session load balancing= mod_backhand?? data relational mapping = Tangram or Alzabo templates or whatever you want to call them = HTML::Embperl/Mason/TemplateToolkit ide = pick an editor with a few hooks to call make, install and restart granted this may not get us everything, but if we could package up the stuff we all use over and over again, wouldn't that get us pretty far? Aaron I'm willing to contribute time to this project if given some input on how to proceed. perhaps take a look at AO - it's a good start at a servlet engine that packages at least a few of the items you've highlighted. i'd love to participate in a project that uses AO, backhand, an o/r mapping tool, and other components to provide an out of the box 2-tier system. i'd also love to see an "enterprise" or 3-tier version of same. let's organize! i suppose i should get the AO sourceforge site up and running eh? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Stas Bekman wrote: But, you all know that php pretty much takes over. Why? For two reasons: 1) initial corporate pushing (press/ads) 2) once well known, the word of the mouth does the rest. oh, there's also the part about php being so much easier to setup and to program ;) if you really feel the need to compete with php in the lowest tier web app space, you need to make simplicity your #1 goal. php is awesome entry level technology, and i almost always recommend it over perl to people who only have the desire to do casual programming for personal sites and small projects. and that's a significant percentage of the people i know doing web programming. i'd love to see us evolve mod_perl with simplicity and ease of use in mind. but precisely because php exists, i think there's a more important goal for us: creating infrastructure that can get perl accepted by the pointy heads in the engineering shops and corporate it depts. competing with java, rather than php. java's got 2 things perl doesn't: a huge, well funded marketing machine, and a large set of standard apis *that were designed to work together* which have almost universal programmer acceptance. i know it's heresy, but while tmtowtdi is a cute slogan, it doesn't market us well outside the circle of perl programmers. how many of you have tried to hire engineers with significant mod_perl experience? it's almost impossible, even in san francisco which is supposed to be the wellspring of geekery. 5 out of 10 perl programmers i interview have not used mod_perl; 4 of the rest have only ever used registry; and the last guy has an equal shot at having experience with embperl, mason or his own homegrown presentation layer. there is almost no talent pool with a consistent skill set. makes it really difficult as a manager to want to continue with a mod_perl-based application when senior engineers who love java are more or less a dime a dozen. we need to create standards for ourselves and fully embrace them. DBI is a great example. the explosion of mod_perl presentation technologies is a great counter example. we need to achieve significant vendor support, in the development tools area, the enterprise software area, the content management area, etc. how many of you use rational rose for analysis design? how many of you would use it for code maintenance as well if it could round trip engineer perl? a premise of the perl philosophy is that it's fun to write code. yes, it is. but it's also fun to make money. and writing innovation applications that people pay for is much different than writing (or often re-inventing) infrastructure components. how many of you are out there trying to re-invent cisco products? i bet zero. you buy them, unwrap them and turn them on. infrastructure software should be the same way. only a few people will ever make money on threads and databases, but many many more will make money on email messages, calendar events, news articles, and item sales. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Nathan Torkington wrote: I picture only 10% of people who build web sites ever needing to use mod_perl directly. I think they're more likely to use the systems that are built *in* mod_perl, like Mason, AxKit, and so on. If there's a with a lot of information about building web sites with those systems, then you'll make people happy. amen! mod_perl is for gearheads. higher layer software is for people who want to achieve a business goal, or even just make a personal site. we have a wealth of gearhead-oriented information, but almost nothing that would convince my php friends to make the switch to perl or help them migrate a site. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Aaron Johnson wrote: I am all for advocating the use of mod_perl, but the basics of setup, install and usability are always going to be key. really? how many people actually need to configure and install mod_perl itself? how many people simply need a really simple templating engine with builtin database access? aren't their needs very different? Does anyone have any figures on how long it takes to setup a mod_perl server vs. a php server? (correctly, not just running) i don't have figures, but from experience i know - once i've compiled httpd, i have almost no real configuration work to do with php. on the other hand, if i want to set up mason, i have to write 10-20 lines of perl code and access them with PerlModule or PerlRequire. if i want multiple mason sites i have to dig back into that perl script. certainly not difficult, but kinda irritating, and takes more effort to maintain, especially across multiple machines. Before we determine whether to advocate we need to term what and how to advocate. agree! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Gerald Richter wrote: I know that S.u.S.E. Linux (at least the german version) include a Apache with mod_perl as DSO ( but I never have tried it, I always compiled Apache/Perl/mod_perl etc. from the source), but they neither have included any of the Apache::* modules or Embperl/Mason/ASP/AxKit etc. i just installed suse 7.0 yesterday. i was psyched to find that i could install mod_perl (dso) with yast. i then fired up the cpan shell and installed Bundle::CPAN, Bundle::LWP, and HTML::Mason. then i had to create my mason handler.pl and do some httpd.conf tweaking. then i restarted and tried accessing the page under mason. result: "document contains no data" dialog in my browser, and no msgs in the error log, even under LogLevel error. commented out the mason lines in httpd.conf, restarted, and lived with flat html files. wasted 30-60 mins that i could have used to do my actual work. I could try to contact them and ask if it's possible to include more of the Apache modules and maybe the guide. please do! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
people won't use the software if you don't give them a compelling reason. mod_perl and the higher layer systems that use it are not as easy to configure or program as php, and they have a lot less support from external software vendors or relevance inside engineering shops than java. we are being squeezed from both ends. i had lunch with doug and jon swartz not too long ago, talking about the possibility of starting a web application infrastructure company based on mod_perl and mason. when we got down to it, the fundamental question was: why not just use java? and we couldn't find any answer other than "i like perl better". and that's not a reasonable business justification. at some point we're going to run out of hobbyists and others who /can/ justify using mod_perl-based technologies because they like perl better. On Tue, 5 Dec 2000, Stas Bekman wrote: Let me stright things out a bit, so you won't get misleaded by my post as a marketing call. What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. The first item is directly linked to the second, as new developers come out from users. That's all. The advocacy project is about making people interested in perl and mod_perl, versus php and java. You see we just loose the testing power and development power because we cannot attract these people to join *our* community. So all the fuss is not about marketing, press and other commercial bullshit. It's about people since Open Source without people will not exist. If we don't ensure that there is a constant income of new people to the project, we cannot ensure the future of the project. I hope that our initiative is better understood now. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Stas Bekman wrote: Therefore if the same job can be done with Perl and Java, why not to have your staff happy? That's the main point I think. Of course if the bussiness suffers because Perl is not good enough, that's a different point. Given that at least the same could be done with Perl and Java, Perl and PHP, Perl and whatever, I want to code in Perl. exactly my point. and in my experience as well as that of many folks i've spoken with, it's just not the case. take CPTH web mail. we used Mail::Folder and MIME::*, but we had to write our own custom subclasses of all of them to deal with our mail store, with folder sorting, with mime tree caching, etc. and now that we're moving to an IMAP backend, we have to write a whole new custom set of subclasses based on Mail::IMAPClient. if we'd have been operating in a java environment, we'd have been able to take advantage of the "insanely great" JavaMail, which comes out of the box with an IMAP backend. a prototype IMAP re-implementation of our mail client took about 3 days, as opposed to the month or more it will take us to do the perl implementation. the availability of application server products in the java world is another example. go look at enhydra enterprise (http://www.enhydra.org/software/enhydraEnterprise/) and tell me that something like that exists in the perl world. and there are many products like this, both commercial and open source. competition flourishes, and the industry benefits. there are lots of folks on the market with experience developing for and operating weblogic. it's easier to hire and you get better time to market. you don't have to spend time re-integrating Apache::Session and Apache::DBI and Apache::WipeMyAss with each new project. this is why i think AO is some important, altho its scale is much smaller. it's a first step towards something like enhydra enterprise for those of us who would, all other things being equal, prefer to use perl. Therefore, we should make converts and when more people will prefer coding in Perl, because they *love* it and it's a legitimate choice, there won't be a question of whether I can afford doing this project in mod_perl, because there will be enough mod_perl programmers to take over it. So to answer your question, the complelling reason is joy and satisfaction. Given that other factors are at least compatible. yes, but we have to get to that point, and we're not there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] mod_perl longevity [Was: mod_perl advocacy projectresurrection]
On Tue, 5 Dec 2000, Ajit Deshpande wrote: Well, the above question pre-supposes that Java is inherently *better* than mod_perl for some definition of "better". it's true. i stayed away from defining better in that msg, but explored in a separate one in this thread. suffice to say, the wealth of existing standards-based components, the focus on creating a platform for enterprise applications, and the competitive vendor landscape for development tools and infrastructure components, all of help define "better" imo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, J. J. Horner wrote: Perhaps if someone makes a mod_perl based embedded scheme like Cold Fusion or PHP, that has some special hooks into Apache for performance that the other solutions don't offer. . . how is mason not like this? Honestly, though, I didn't believe the strength of mod_perl rested on the Mason type modules. I thought the strength of mod_perl was having a perl/Apache API. Having an easy way to interact with Apache using everyone's favorite language was what sold me on Apache. we very rarely use the apache api anymore. i prefer the abstraction layer of a templating engine, for ease of use and for maintainability by larger teams. i used to be shocked that nobody i worked with wanted to learn how to configure apache or use its api. now i'm right there with them. give me Apache::Request and mason and i'm happy. i know there are several people on the list who swear by "all handlers, all the time". i've never heard anybody give a reason for that preference that actually made sense to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Dave Rolsky wrote: Each has its advantages. Perl is good for real programmers who are going to write code to actually solve a problem. Java is good for monkeys who think that buying a $100k app server and tweaking it via a monolithic API will give them what they want. c'mon dude, offer something constructive to the thread or stay out of it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Ajit Deshpande wrote: IMHO, it shouldnt be that difficult if you make some good assumptions. For example, how difficult will it be to maintain the following package: 1. Assume Perl 5.5.3 OR 5.6.0 2. Assume latest Apache and static mod_perl 3. Assume latest Apache::DBI, Apache::Session, 4. Assume latest HTML::Mason (I cant speak for the others, yet) 5. Assume latest MySQL Now, with the above, I think we can maintain a basic demo, templating system with session management using Apache::DBI fairly easily. fwiw, those are exactly the components the current version of ao supports out of the box. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Matt Sergeant wrote: On Tue, 5 Dec 2000, brian moseley wrote: the availability of application server products in the java world is another example. go look at enhydra enterprise (http://www.enhydra.org/software/enhydraEnterprise/) and tell me that something like that exists in the perl world. http://www.mediasurface.com Sadly though, its only one product in a sea of Java products. doesn't look like enhydra enterprise at all. i'm not talking about a content management system, i'm talking about a scalable middle tier service upon which any type of application can be built. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, kevin montuori wrote: i'm not sure about "all handlers, all the time" but a good deal of what i'm using mod_perl for is session management, credential maintenance, custom logging, on-the-fly compression, and other "housekeeping" tasks. i think only 10% of my handlers are content handlers, the other 90% do things neither CGI nor an application server are going to do. in fact, these are exactly the problems ao is meant to solve. the idea is that for now, we provide a presentation tier environment with hooks to allow you to integrate middle tier functionality, but eventually it would be nice to also create a real j2ee like environment with separate front and middle tiers, where presentation and business logic can be varied and scaled separately. if for no other reason than time to market, it's nice to have access to the server API in Perl rather than C. it took only hours to whomp up handlers to help integrate netegrity's siteminder product into our existing site; it would have been weeks if it had to be written in C. yup, it's always going to be nice to have direct access to low-level components. as someone pointed out earlier, some people will always require it. i'm shooting to make 80% of people happy rather than 20%. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Matt Sergeant wrote: But I'd really love to hear some rational discussion on transaction object support. There are open source J2EE implementations - would it be possible to look a porting the transaction management components of that to Perl? Would this be desirable? Personally I put all transaction critical stuff in the database, and rely on RDBMS transaction support, but I've never done J2EE, so I'm curious as to the advantages. transaction management, message queuing, container managed persistence, a naming/directory interface, a monitoring (snmp) framework, enterprise application integration... these are all things in j2ee and associated products that we don't have. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Perrin Harkins wrote: Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? Use an RDBMS. what about transactions that span data sources? yes, this does happen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Perrin Harkins wrote: Brian, you've been taking a beating on this thread. I don't want to add to it, but you did raise a couple of interesting questions in this post. a beating? i don't think so at all, it's been one of the most restrained threads on this range of topics in a long while. and judging from the amount of personal mail i've gotten, a lot of people seem to agree with me! :) Personally, I'm kind of pleased that nothing like that exists in the perl world. It looks like a recipe for a slow site to me - complexity for the sake of complexity. But I've been burned by Java "application servers" before so I may be a bit prejudiced against Enhydra. I think the part of server-side Java that has the most value is the basic servlet API. Personally, I find it pretty easy to replicate those services in mod_perl without doing any additional coding, but I know you believe it's still too difficult for newbies, and you may be right. cool, you should get a lot of use out of AO then :) i definitely understand your viewpoint, and i realize that there will be a lot of people who don't need the kinds of things i'm proposing. but there are also a lot who do want these types of components, and they really don't have any options. Part of the problem then is that perl is all things to all people. This thread has already covered both the "it's harder than PHP", which is true, and the "it's not as polished as Java", wich is also true. Some projects, like Embperl and Apache::ASP, have gone a long way to make the barriers to entry lower for the PHP types. There has also been a lot of effort to make more polished web pages and documentation for some mod_perl projects lately, Mason and AxKit being cases in point. I doubt it will ever compete with Java in this regard though, since no single mod_perl project is likely to get the same level of promotion that a WebLogic can muster. The mod_perl message will probably always be about choice, flexibility, and source code. eh, there's a perl infrastructure support/services company waiting to happen. i just personally don't have the motivation to do something on the scale that i think is necessary. maybe this discussion is giving others ideas, tho... I think Apache::WipeMyAss auto-configures as of 0.3. But seriously, do people have that much trouble using these defacto standard modules? Maybe they need some more work in certain areas if they don't function correctly "out of the box" for most people. i think a lot of it is that they are all configured in different ways, and you have to write glue code to tie them all together. a good example is the stuff you have to do to configure mason. dave's implementing apache config directives for some of that, which i think is a good step, but i personally don't like having the configuration of my application mixed up with the configuration of my web server. so one of the things that AO has is a nice flexible configuration system which allows all these various knobs to be tweaked in one place, with no code writing. the net effect is that it's extremely simple to clone a template servlet app, spend 30 seconds tweaking, and have a running app with authen and authz, session persistence, logging, etc. it's all the same glue code shit i used to write for each of my projects, now it's reusable and packaged up neatly with a bow tie. rad. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Perrin Harkins wrote: Someone else brought this up with me off the list. Briefly, I said that this doesn't usually happen with web sites for performance reasons and that major RDBMS the world doesn't revolve around two tier web sites. consider a scenario in which somebody uses a web interface to signal an action, which is placed into a message queue. on the other end of that queue, a service handles the event with a transaction that spans multiple third tier systems. this is the kind of architecture that is begging to be embraced by perl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Gunther Birznieks wrote: I think the issue is Perl for web applications advocacy rather than mod_perl advocacy. If more people thought using Perl for web apps was cooler and easier than using PHP, then they would use Perl and then graduate to mod_perl when they were ready. well said. As it is, PHP has 1-up on CGI/Perl. PHP is FAST while still having an easy programming model. Having an easy programming model was Perl's claim to fame and why web apps fluorished in CGI/Perl. But PHP added one thing -- speed -- and they are taking it all away from Perl. well there's also the in-core support for things like database access, imap, etc etc. it's very easy to go to the php manual and look up the api for interacting with these services. you don't have to go to some component archive, look for something that suits, choose between 3 or 4 components that all do the same thing but in different ways, figure out how to configure the thing and work it into your build, etc. The model is similar to FastCGI, but SpeedyCGI is trivial to setup unlike FastCGI which requires modification to the app. yeah, one of the main goals of AO is to be portable between mod_perl, FastCGI, SpeedyCGI and other process models. app writers should be able to assume that the servlet environment provides a standard set of services without having to understand HOW, if that's their choice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
