Re: speeding up CGI.pm
Stas Bekman wrote: While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? From an outsider's perspective, I agree. For some previous discussion (April 16, 2000) http://marc.theaimsgroup.com/?l=apache-modperl&m=95587404903236&w=2
Re: OSCON ideas - missing proceedings
Randal L. Schwartz wrote: "Nathan" == Nathan Torkington <[EMAIL PROTECTED]> writes: Nathan> Not for two years at least (the duration of the contract with the Nathan> Portland hotel). The San Diego hotel was much more expensive and Nathan> remote, compared to the Portland hotel. I think people are really Nathan> going to enjoy being in the middle of a city at this year's OSCON. Yes... the number of things that are within walking distance of the hotel is rather nice. The waterfront park should be rather spectacular, especially at night when the 14 bridges across the Willamette are lit up in their own unique ways. I agree. No matter what, speaking as someone who hasn't travelled around America all that much, I think it's fun to know that the OSCon is in different places every couple of years and to get exposed to those places. Also, speaking as someone who earns money in a non-US currency, having a less expensive place to stay at is much nicer. I am sure the self-employed in the US also feel similarly... (ie anyone who doesn't have a company paying for it...and isn't a shareholder of that company). Later, Gunther
Re: OSCON ideas
[EMAIL PROTECTED] wrote: I wonder if telecommuting plus occasional travel for face-to-face would sell better than pure telecommuting. Is this done very often in telecommute situations? This is exactly what I hope to propose if the need arises in my situation. Would love to hear from others who have had success doing this (maybe offline if people feel this is straying too far). I don't know if it is really appropriate for OSCon, but I think topics on telecommuting tips and tricks definitely tug at the heart strings of many programmers out there. I know that for my own company, I both like and dislike telecommuting. On the dislike side, I don't think I would ever hire someone whom I did not know for telecommuting even if they came recommended because everyone needs to be managed differently and it's very hard to learn the "body language" without having been there in person for 6 months to a year. This adds a lot to inefficiency of communication which means money out the window when I could just otherwise hire someone local (unless local talent were not withstanding). But we do support telecommuting. After a couple years with us, our R&D director moved to Melbourne (instead of Singapore), and when our webmaster moved back temporarily to New York for personal reasons, he telecommuted for months. Anyway, how to make this "on topic" for OSCon? I am not sure. Perhaps somewhere in this seed of an idea lies a study/comparison of Open Source Development models and tools being very similar (with perhaps some interesting differences) between telecommuting programmers in a corporation in terms of the methods and tools they use to do their jobs.
Re: OSCON ideas - more talk ideas
Nigel Hamilton wrote: HI, I'd really like to see talks on: 1. Web Server Compression - a comparison, between mod_gzip, DynaGzip Compress etc, pros / cons, SSL compression, and example configurations 2. Application Server Options - a comparison between pure-perl, Apache/mod_perl, POE, SpeedyCGI etc I have done this a couple years ago with Pure-Perl, mod_perl, SpeedyCGI, Velocigen at OSCon. I can forward you my notes if you are interested. But I didn't do it at the level of POE. Comparing POE to mod_perl and SpeedyCGI is kind of like comparing apples and oranges. It feels more apt to compare SOAP::Lite, POE, PerlRPC, ... in terms of a comparison of servers in the same "category". And yes, I agree... I would like to see a comparison of SOAP::Lite, POE, PerlRPC, and anything else like them... :) Nige
Re: OSCON ideas - MVC talk
Andy Wardley wrote: Ask Bjoern Hansen wrote: I am planning to submit a proposal for a introduction talk on MVC in a web environment. [...] Like Perrin I would like feedback on the idea before putting in my proposal. I like the sound of it, but I should warn you that I have a personal crusade against inappropriate use of the phrase "MVC" in relation to web development. I like the sound of the proposal also but more because I think that anything Ask is itching to say is probably going to be interesting. So I trust that he'll give a good talk. However, like you, (but in a different way), I am not necessarily so keen on the topic of MVC. I think most programmers know what MVC is all about, the word is likely mentioned in the docs of most template toolkits which probably has led many people to already read the copious volumes of stuff written on the web about MVC, and likewise the mailing lists of many of the open source Perl toolkits out there probably digress into talking about MVC every 3-6 months at some point. :) In other words, I guess I am not sure how interesting MVC really is (to me). It feels like knowledge of MVC is everywhere to be found. So personally, I would not be interested in an MVC talk just for the sake of imparting knowledge on MVC. But if there was an interesting novel twist to it then that would be more interesting. Perhaps rather than asking our opinion on the "title" of these talks, a 1-paragraph abstract would be useful to also include in terms of giving an idea of the talk. My limited imagination is kind of turned off on the idea of a talk as an intro to MVC. But if the abstract sounded more interesting than my limited imagination is allowing it to based on a generic title/subject name, then something in that might spark more interest to me. It also could be that an intro talk isn't something that would spark interest on the people on this list because... well, those who are the most vocal here aren't really "intro level" people. But an intro level talk might interest the silent majority who would pay to attend the conference and could be interested in that Intro knowledge from a "mentor" instead of reading it on the web. So please don't let my naysaying discourage you. I could be completely wrong. Later, Gunther
Re: Database Pooling
If I recall correctly, Jeffrey Baker (author of Apache::Session) wrote an extremely lucid and well thought out argument about why the way mod_perl pools connections is just as well as Java in reality. Try searching for his name in the mod_perl list archives.. I think he wrote this over a year ago, but less than 2 years ago. Later, Gunther Michael Teter wrote: Howdy. I'm very new to mod_perl, so if this question makes no sense, say so :) My understanding is that database access via mod_perl is pooled, but only per-httpd. So if I had 10 active httpds running, I would have 10x(number of connections per pool). In contrast, my Java/JSP/Servlet solution has a single pool. I'm trying to evaluate mod_perl to use instead of my current Java-based solution, but the potentially high number of database connections scares me. Do production, public mod_perl-based sites have 10s or 100s of database connections open? Any direction will be appreciated. Michael __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Perl Cookbook modperl chapter
Stas Bekman wrote: Hill, Ronald wrote: It's much simpler than that. You need two sentences: 1) under mod_perl, globals remember their values from the previous request, so you can cache the connection with: $dbh ||= myconnect(); But Apache::DBI implements pinging (immediate or timing based) which is much superior to this. Some databases drop connection otherwise. Or consider the case where the database goes down and then all the $dbh becomes invalid. Apache::DBI would recover gracefully I think. But the above method wouldn't. 2) If you rdbms supports cached statement handles (which most do), you can use Apache::DBI which caches database connection without needing to change any of your code. I am not aware of Apache::DBI caching statement handles. Are you sure that Apache::DBI does this? Or is it a side effect of caching the database handle. If it is the latter, then then caching with #1 above would not solve the problem. If it is the former, perhaps someone can add a global setup variable to Apache::DBI to turn this feature off. eg $Apache::DBI::statement_handle_caching = 0; # default = 1 But of course I agree that it's a good idea to mention this topic. I suggest that many other topics are to be mentioned but replace discussions with pointers to the relevant chapters of the mod_perl books and online documentation. So newbies, know what to look for. It's not obvious that database connections can be cached. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Perl Cookbook modperl chapter
Nick, I think you raise valid points that I think Nathan and the reviewers should take on board when they do this chapter and subsequently review it. However... 1) I believe that rather than entirely naysay that some common cookbook items can be covered in a mod_perl chapter, I would prefer to see what Nathan et al come up with rather than discourage them from trying at all. Will it be "futile" as you suggest? Maybe. But then Nathan and the reviewers can choose to cut the chapter. Will it be too complex and therefore cause problems for readers? Maybe. But I think I would trust Nathan and his reviewers to judge after it's done. And again, there is the option of always cutting that chapter as mentioned above. In my past writing life, I've cut plenty of chapters when after seeing a whole book, deciding that they didn't fit (or worse, where it just was a bad chapter I wrote). I suspect Nathan has done the same in his lifetime and I would trust his professionalism in this manner. In other words, I think we should trust that Nathan et al have been writing/editing for a long time. Can they make mistakes? Yes. No one is perfect. But I also trust that their experience will allow them to come up with something for this chapter which will suit a market need. And if it doesn't, to not use that material. But I think it would be sad not to try at all since there could be benefits to this chapter. 2) Will mpdc lose sales? I suppose so. Short-term maybe. But then should Stas stop publishing his book? MacEachern and Stein theirs? Surely they also overlap with mpdc. And there will be other books by other publishers that will overlap with mpdc as well. I suppose that I feel like I am more of an economic optimist than you. While short-term, it may appear that more mod_perl books being released would cause fewer sales in a market that is "fixed", long-term, I believe having more written material about mod_perl will actually help the market. Provided it is done well, I think a chapter in TPC that covers mod_perl explicitly is a good idea also for spreading mod_perl community advocacy and learning. Nick Tonkin wrote: On Wed, 11 Dec 2002, Nathan Torkington wrote: Actually, we do cover mod_perl--we published the Eagle book, "Writing Apache Modules ..." way back in 1999. Yes, I have had my now dog-eared copy since then :) There's no way that 20 recipes in the Perl Cookbook will compete with the what, 250? in the mod_perl Developer's Cookbook. Especially when the introduction and each recipe points the reader to the mpDC. The Perl Cookbook has over a hundred thousand readers. I want to push as many as I can onto the mpDC. If that's competing, then I can only say that you have a strange sense of competition :-) Ahem, well, without wanting to get into a fruitless argument about this part, I might say that you have a strange idea of how to push people onto their book. At close to $50 a pop, I know I'd think twice about purchasing the mpDC if I'd shelled out for the Perl Cookbook and it had a section on mod_perl. I venture to say Geoff et al will see less overall sales, rather than more, if the PCB has a mod_perl section. This notwithstanding the fact that _some_ people _will_ no doubt have their appetite whetted and move on to the definitive mpDC. (Of course there's nothing definitive about Perl, that's the whole point about TMTOWTDI, right?) Trying now to cover highly complex topics like "Authenticating in mod_perl" in a recipe in a chapter of the Perl cookbook is futile. It will only serve to oversimplify and lead novices into a false sense of competence. This was really my point. The Perl Cookbook has never pretended to be the definitive guide to anything it covers (have you seen the Perl Cookbook? I recommend it :-). Each recipe includes references to definitive sources of information (manpages, web sites, and other books). I have also owned the Perl Cookbook since it came out. It's very useful as exactly what it says: a cookbook. You can turn to it for a recipe to accomplish a small, simple task which you guess others may have tackled before you. You can also use it as a tutorial, if you choose to, by studying each chapter as a whole. I do not believe that mod_perl lends itself to the former, and I think that the mpDC more approaches the latter. One can go look up a recipe, true, but it is useless without a pretty thorough prior understanding of mod_perl. So, I stand by my prediction that just putting a few mod_perl recipes in the PCB will lead more than a few people into more problems than solutions. While I've been writing this reply a few people have responded to your request for content suggestions. Stacked handlers, among other things ... I think it just goes to show that there can be no successful trivial coverage of mod_perl. (That's why the Eagle book, and the mpDC, are so good.) - nick
Re: References for modperl usage in financial institutions?
Does it have to be mod_perl in order to help your case? I gave a talk on Perl being used for webapps for investment banking at the 1999 Perl Conference and Morgan Stanley allowed a champion of Perl deliver a keynote at the OReilly Open Source Conference in the year 2000. But neither of us talked about mod_perl specifically. Both presentations might be available from OReilly if you register for their conference portal. I think there may also be a chapter or two on using Perl in a financial institution in the book "Applied Perl" from the publisher Hungry Minds (IDG or Wiley subsidiary?) (compiled advocacy articles with Peter Williams as editor and author of a couple chapters). Marcin Kasperski wrote: I am looking for some examples of modperl being used in financial institutions (banks, brokers, ... but also large e-commerce). I spent a few hours searching the internet but it seems such a information is not easily available. I am interested in both official and unofficial information. Technical details are not necessary. Thanks in advance for any reply.
Re: Yahoo is moving to PHP ??
You would think if they want an anal scripting language they would move to python not PHP. :) John Saylor wrote: Hi ( 02.10.30 03:22 -0500 ) Perrin Harkins: They didn't make their decision on performance though. They seem to have been most influenced by the idea that perl allows too much flexibility in coding style, although I can't see how PHP is going to help with that. Wow, I'd like what *they* had for lunch! Quasi-seriously, as someone who has had to maintain mountains of bad perl code, I know TMTOWTDI can have a downside; but the openness of the language is what has lead to its greatness ...
OT: Re: Hoping you could give advice
Todd Cranston-Cuebas wrote: >Any other thoughts? > > Yeah, this is off topic, please label it as such. :) > >
Re: Mixing TOMCAT and mod_perl sessions
What you could do is write an Apache::Session driver that instead of
storing to a file, passes the session id as a call to a web service that
gets and sets session data using parameters sent to a servlet running in
the same context as the sessions where your Java servlets/JSPs run.
I've not done it, but I think it would be awesome if sessions could be
shared between Java Servlets and Perl. We have a lot of apps written in
both technologies ourselves (banking in Java, portal stuff in Perl)
I don't think doing this would be too hard.
Later,
Gunther
At 08:36 PM 8/12/2002, Yair Lenga wrote:
>Greetings,
>
>The website I'm supporting is running both TOMCAT applications ('.war'),
>and has mod_perl scripts (all of them are registry - CGI scripts). I have
>the following requirements:
>* The user identification information must be shared between TOMCAT
> and mod_perl (so that the user does not need to login twice).
>* No data sharing between mod_perl and TOMCAT application - but each
> of them need to store some persistent data.
>* Session should be persistent across server restarts (which excludes
> shared memory based solutions).
>I'm currently using 'home-grown' session management, where each session is
>represented as a file. Both TOMCAT (4.0.4), and mod_perl (Apache::Session)
>can serialize session state. Can anyone suggest a smart way to get the two
>to work together - at minimum, I need to be able to create and destroy
>sessions, and to have the user id shared between the two. Preferably,
>using files (and not mysql).
>
>Thanks,
>Yair Lenga
>
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Office: (65) 64791172 Mobile: (65) 96218290
Getting to the Guide PDF on the new website
At 09:24 PM 7/13/2002, Stas Bekman wrote: >Gunther Birznieks wrote: >>I agree! It is great work. It looks really slick. > >:) > >>Unfortunately, the mod_perl guide documentation area has lost >>functionality. I wanted to download the "latest" guide before my 23 hour >>flight to the USA (to read on the flight) and was dismayed to find hours >>before my flight that it is impossible to get a full HTML or full PDF >>download of the entire guide anymore... >>You can get a PDF of single pages (of which I don't know the reason?), >>but the guide itself is quite hard. > >eh? what do you mean? it's all there, go to: >http://perl.apache.org/docs/1.0/guide/index.html >click on the pdf button in the right upper corner and you get this: >http://perl.apache.org/docs/1.0/guide/guide.pdf > >Notice though, that parts non-specific to mod_perl 1.0 has now moved to >http://perl.apache.org/docs/general/index.html Oh I see it does work. I suppose the PDF buttons on every page is what confused me though. So if you go to the front-page of the docs section, just the front-page gets generated in a PDF, if you go to a page within the guide, then just that section gets generated. The only PDF icon that actually generates a full guide (and it is inconsistent with what the rest of the website PDF icons do) is the actually guide.pdf. A "constructive" suggestion would be that the icon for PDF on the main guide page should explicitly say "PDF of entire guide" or something other than the simple PDF icons on all the other pages of the website. Or perhaps remove the PDF icons entirely off the rest of the website. After all, who really wants to generate a PDF of a single HTML page they already read? >__ >Stas BekmanJAm_pH --> Just Another mod_perl Hacker >http://stason.org/ mod_perl Guide ---> http://perl.apache.org >mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com >http://modperlbook.org http://apache.org http://ticketmaster.com > __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Re: ANNOUNCE: the new perl.apache.org is alive now!
I agree! It is great work. It looks really slick. Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the "latest" guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. I was able to find a copy on someone else's website... but it was mighty hard on the new one. Anyway, otherwise it looked very slick and was easy to navigate. At 06:10 AM 7/13/2002, David Kaufman wrote: >"Stas Bekman" <[EMAIL PROTECTED]> wrote: > > > As you may know, the work on the new mod_perl site started in > > September 2001, and after almost a year we are glad to present to you > > the outcome of this work at the expected location: > > > >http://perl.apache.org/ > >fist, let me say: Great Job! the new site looks fantastic, a *vast* and >long-awaited improvement. > >i still notice, however that the *content* of the "Sites Running mod_perl" >page doesn't seem to have been updated. about 6 months ago, i sent notices >about two sites that we (Vanguard Media) had launched to the email address >that used to be on that page, but they were never included. > >is this being actively maintained now? should i re-send now to the docs-dev >mailing list? > >thanks and, again, Great Work! > >-dave __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Re: Knowing your limitation - was Re: [JOB] Crack OOP Perl whitebox tester wanted
he >>most quality solution... >> >>I work for Cisco Systems in our RTP (NC) office. I work with two >>different groups, one based in San Jose and the other based in Ontario, >>as a "virtual team member" (what we call our telecommuter positions). I >>only bring all this up because I'm in exactly the role you've outlined >>here, and to be honest I don't think I would BE as successful as I am if >>I were located directly with either of these teams. >> >>The need to have everyone "all together" is usually indicative of a >>larger problem in team dynamics, and communications. It usually >>represents a team in which "charasmatic" leadership is more important >>than technical know how or ability to get a job done. Now don't get me >>wrong, for a person to BE a successful "virtual team member" they have to >>have great communication skills, and be open to working with others in >>multiple formats to enable the best level of teamwork and participation. >> >>With all this said, and based on my own personal experience in this role, >>I can tell you that what you're asking for here is a person to walk a >>VERY shape edge between the need to bring the best and brightest from >>people, without making it seem "personal". Actually having this role as >>an "outsider" to the day to day politics and interpersonal sabatoge of >>most bay area offices (yeah I lived there five years during the "boom") , >>gives a layer of abstraction that makes the job easier to perform. When >>someone is questioning things like style, or code effeciency it comes >>across MUCH easier (more acadimic) when that person is a "talking head", >>an IM box, or a voice on the telephone. It becomes less "personalized" >>and easier to "pick and choose" the best componants into a greater >>whole. It also isolates the individual who may end up doing a lot of >>refactoring to present the final solution. >> >>Just something to consider. Open youself to the best people in the world >>and don't accept just the best you can find in your area, and you'll find >>that you solutions aren't also as limited... >> >>-Zac Morris >> >>- Original Message - >>From: Tom Mornini >>To: [EMAIL PROTECTED] >>Sent: Thursday, June 20, 2002 11:30 PM >>Subject: [JOB] Crack OOP Perl whitebox tester wanted >> >>We're 1 year into development of a system that is OO Perl, mod_perl, >>DBI and DBD::Oracle on Linux. >> >>We've spent a lot of energy doing it right and writing tests as we go. >>This has given us huge benefits in the life of the project, but our current >>whitebox tester has decided to move to Washington, D.C. so we need >>somebody to fill his large shoes. >> >>If you're a good Perl programmer who has a strong sense of "the way it >>should be" and can be simultaneously mean, nasty, angry, distrustful and >>unforgiving to Perl code and the opposite to people then we'd like to >>talk to you. >> >>This person doesn't do new development, per se, but he is responsible >>for making things better via testing, fixing, documentation and refactoring. >> >>This is a full time job at an office in the South Park area of San >>Francisco, >>California, USA. Telecommuters are NOT what we have in mind. Call us >>old fashioned that way. :-) >> >>Pay and benefits are good, though it's no longer 1998. :-) Best benefit >>is working with a small group of people that are highly motivated by >>doing it right. >> >>-- >>-- Tom Mornini >>-- eWingz Systems, Inc. >>-- >>-- ICQ: 113526784, AOL, Yahoo, MSN and Jabber: tmornini > __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Re: separating C from V in MVC
At 12:58 PM 6/14/2002, Dave Rolsky wrote: >On Thu, 13 Jun 2002, Rob Nagler wrote: > > >I'm not a big fan of O/R. I prefer R/O. But to each their own. Would one of you mind providing a 1 paragraph definition of each? I am afraid that I am starting to get lost in the semantic differences of controllers and actions and O/R, R/O?
RE: OSC early bird and mod_perl T-Shirts
Maybe this year Randal Schwartz can get his idea implemented. I think he had suggested a motto last year that people seemed OK with but then the T-Shirts never got done in the end... Ah, the annual motto vote... :) Just re-read the same thread in the archives last year. Later, Gunther At 06:55 PM 6/11/2002, John Bass wrote: >mod_perl: The camel with wings > >John > >-Original Message- >From: Lupe Christoph [mailto:[EMAIL PROTECTED]] >Sent: 11 June 2002 11:51 >To: Leon Brocard >Cc: mod_perl list >Subject: Re: OSC early bird and mod_perl T-Shirts > >On Tuesday, 2002-06-11 at 10:44:26 +0100, Leon Brocard wrote: > > > Yup, I have a designer here who is willing to come up with something. > > Constructive ideas welcome offlist. Better slogans than "modperl: the > > only way to fly", "modperl: obey your thirst" etc. very welcome too >;-) > >SCNR: > >Quetzalcoatl: The Feathered Snake > mod_perl: The Feathered Camel > >Profound excuses, >Lupe Christoph >-- >| [EMAIL PROTECTED] | http://www.lupe-christoph.de/ >| >| I have challenged the entire ISO-9000 quality assurance team to a >| >| Bat-Leth contest on the holodeck. They will not concern us again. >| >| http://public.logica.com/~stepneys/joke/klingon.htm >| __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Re: [Templates] Re: Separating Aspects (Re: separating C from V in MVC)
At 04:14 PM 6/7/2002, Tony Bowden wrote:
>On Thu, Jun 06, 2002 at 05:08:56PM -0400, Sam Tregar wrote:
> > > Suppose you have a model object for a concert which includes a date. On
> > > one page, the designers want to dipslay the date in a verbose way with
> > > the month spelled out, but on another they want it abbreviated and fixed
> > > length so that dates line up nicely. Would you put that formatting in
> > > the controller?
> > In the script:
> >
> >$template->param(long_date => $long_date,
> > short_date => $short_date);
> > In the template:
> >
> >The long date:
> >The short date:
>
>Can I vote for "yick" on this?
>
>A designer should never have to come to a programmer just to change the
>formatting of a date.
>
>I'm a huge fan of passing Date::Simple objects, which can then take a
>strftime format string:
>
> [% date.format("%d %b %y") %]
> [% date.format("%Y-%m-%d") %]
And the latter does not require a programmer?
Re: [ANNOUNCE] The New "mod_perl" logo - results now in...
At 10:46 PM 3/15/2002, John Saylor wrote: >Hi > >( 02.03.15 10:03 - ) Jonathan M. Hollin: > > However, I request your comments on this idea: should we have just one > > button (helping to develop a distinct identity for mod_perl) or should > > we have several (for choice)? It's up to you... > >TMTOWTDI, of course- multiple buttons! Those of us who have seen the movie Office Space know these as "Flair". At least 14 are mandatory! :)
Re: here is a good modperl question on perlmonk
Philippe Chiasson had a really nice talk on setting up developer teams on mod_perl at ApacheCon 2001. Covers everything from CVS to deployment. You may want to see if you can get the slides from him ([EMAIL PROTECTED]) if you are interested in the details. Later, Gunther At 07:43 AM 3/6/2002, Medi Montaseri wrote: >Caller wirtes > > > we've just migrated our 80K line pure perl web application to > mod_perl...ah... > > so much aster... can anyone advise on their experiences for setting up > > apache/mod_perl for team development? up till now, we've all been running > > our own copy of sources out of our home directories, and running a > separate > > apache instance for each developer seems like overkill > >Source Control or Revision Control will always be there, no matter if you >work >out of one box or many boxes. Further I don't see anything different about >mod_perl >vs C++. There are all source codes. > >My suggestion would be to install a Linux on your developer's PC and keep >with the distributed model. Now everyone can use a common web tree and >at integeration, bring all of them to a staging box, QC it and ship it to >production. > >Caller can also buy some content management software like Interwoven's >TeamSite >product that provides a virtual workarea, for about $300,000. Its always >Make or Buy. >Isn't it. > >clayton cottingham wrote: >>thought someone might like to have a gander at this: >><http://perlmonks.org/?node_id=146303>http://perlmonks.org/?node_id=146303 >>look forward to seeing your replies!! > >-- >- >Medi Montaseri [EMAIL PROTECTED] >Unix Distributed Systems >Engineer<HTTP://www.CyberShell.com>HTTP://www.CyberShell.com >CyberShell Engineering >- __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: New mod_perl Logo
At 04:50 PM 1/31/2002, brian moseley wrote: >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. I was thinking if we renamed mod_perl as "George Bush" it would do quite well in the political polls. Might even be elected for president. And then we'd rule the country!!
Re: New mod_perl Logo
How could another name look nice on your resume if they don't know what it is ? Why don't you just "nickname" mod_perl as something else and then put THAT name on your resume if you are so concerned about naming. At 09:36 PM 1/30/2002, Paul Cotter wrote: > > > "mod_perl" is a lousy name. > >It is causing me a problem. My potential customers have heard of Perl and >Apache, MySql and Postgres, but they dot like the idea of perl modifying the >Apache processing. It strikes them as tinkering round with the internals and >liable to cause problems 'when we upgrade' or 'move to another platform'. It >also does not look good on a resume when you are sending it to someone who >has never heard of it. You are never quite sure whether to Wordcap it or >not. Give it some other marketting name, even if it keeps its original name >in places like this. Anything will do, WebBlast, Insiouxiance, Perlandra, >Exsight, Insite, HowtoSite - I really do not mind. > >Regards - Paul Cotter __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: New mod_perl Logo
I agree. mod_perl is a technology not a platform. Java is called Java, Servlets are called Servlets, but products on top of the technology (eg app servers) are usually have the name "Orwellian Pearlz Factory". If you wanted to use a marketing name, you should have just told them you were using one of the frameworks on top of mod_perl like AxKit or Mason. At 08:59 AM 1/30/2002, Robin Berjon wrote: >Hi ct ! > >On Wednesday 30 January 2002 01:29, Chris Thompson wrote: > > Well, I'd like to just throw one idea into the mix. It's something that's > > bugged me for a long time, no better time than the present. > > > > "mod_perl" is a lousy name. > > > > There, I've said it. > >This discussion has occured already. The conclusion was simple: the name >won't change. Doug cut the talk saying that he won't change the name, and I >must say I agree. > >That isn't to say your points are invalid, you're concern is justified. The >solution here is not to change modperl's name. modperl, in a way, is a low >level thing. It's "just" Perl + Apache. When in need of a convincing name, >say "I use Foo" where Foo is the name of something that runs on top of >modperl. "I use AxKit", "I use FooAppFramework", etc. can sound a lot better. > >Of course, on top of that you need a good looking website with marketing >talk. In any case changing the name alone doesn't help. Website content >welcome ;-) > >-- >___ >Robin Berjon <[EMAIL PROTECTED]> -- CTO >k n o w s c a p e : // venture knowledge agency www.knowscape.com >------- >Paranoids are people, too; they have their own problems. It's easy >to criticize, but if everybody hated you, you'd be paranoid too. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: UI Regression Testing
From the description of your scenario, it sounds like you have a long product life cycle etc. I think your testing, especially regression testing and the amount of effort you put into it makes a lot of sense because your software is a long-term investment possibly even a product. I think you can "worry" about an API not having a test for it, and I do a bit, but I don't lose sleep over it. The reality is many APIs succeed OK without tests and maybe a few grumbles hear and there if and when things break. I've rarely seen a documented API break in such a significant way that either I programmed or used from someone else that I could not easily rectify it or go back to a previous version until it was resolved. ie major API changes usually have a way of being known anyway very quickly. Would API tests for every API in existance solve that? Could be, probably yes. But is it worth all the extra coding time for those tests? I don't think so. Not for all APIs. To each his own I guess. I agree with tests for some things, just not for all things including not all APIs. At 08:59 AM 1/26/2002, Rob Nagler wrote: >Gunther Birznieks writes: > > the database to perform a test suite, this can get time consuming and > > entails a lot of infrastructural overhead. > >We haven't found this to be the case. All our database operations are >programmed. We install the database software with an RPM, run a >program to build the database, and program all schema upgrades. We've >had 194 schema upgrades in about two years. > > > unit testing being done on the basis of writing a test class for every > > class you write. Ugh! That means that any time you refactor you throw away > > the 2x the coding you did. > >By definition, refactoring doesn't change observable behavior. You >validate refactorings with unit tests. See http://www.refactoring.com > > > To some degree, there should be intelligent rules of thumb as to which > > interfaces tests should be written to because the extreme of writing tests > > for everything is quite bad. > >Again, we haven't seen this. Every time I don't have unit tests, I >get nervous. How do I know if I broke something with my change? > > > Finally, unit tests do not guarantee an understanding of the specs because > > the business people generally do not read test code. So all the time spent > > writing the test AND then writing the program AND ONLY THEN showing it to > > the users, then you discover it wasn't what the user actually wanted. > So 2x > > the coding time has been invalidated when if the user was shown a > prototype > > BEFORE the testing coding commenced, then the user could have confirmed or > > denied the basic logic. > >Unit tests aren't about specs. They are about APIs. Acceptance tests >need to be written by the user or written so the user can understand >them. You need both kinds of testing. >See http://www.xprogramming.com/xpmag/Reliability.htm > >Rob __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: UI Regression Testing
I suppose it depends on what you want out of testing. Frequently, unit testing is OK in simple applications. But in an application whose job it is to communicate with a mainframe or back-end databases, frequently the tests you might perform are based on some previous persistent state of the database. It takes a lot of effort in other words. For example, 2-3 programmers could easily get away (through normal testing) with sharing a database. But generally if you require each programmer to have their own database and their own system completely where they are constantly wiping the state of the database to perform a test suite, this can get time consuming and entails a lot of infrastructural overhead. I've seen some articles that demonstrate doing something with test XML backends to emulate database retrieval results, but these seem quite hard to set up also. I agree that testing is great, but I think it is quite hard in practice. Also, I don't think programmers are good to be the main people to write their own tests. It is "OK" for programmers to write their own tests but frequently it is the user or a non-technical person who is best at doing the unexpected things that are really were the bug lies. The other annoying thing about programmers writing tests is deciding where to stop. I believe the HTTP level for tests is really good. But I see much unit testing being done on the basis of writing a test class for every class you write. Ugh! That means that any time you refactor you throw away the 2x the coding you did. To some degree, there should be intelligent rules of thumb as to which interfaces tests should be written to because the extreme of writing tests for everything is quite bad. Finally, unit tests do not guarantee an understanding of the specs because the business people generally do not read test code. So all the time spent writing the test AND then writing the program AND ONLY THEN showing it to the users, then you discover it wasn't what the user actually wanted. So 2x the coding time has been invalidated when if the user was shown a prototype BEFORE the testing coding commenced, then the user could have confirmed or denied the basic logic. The same frequently and especially is true for UIs. Later, Gunther
Re: Single login/sign-on for different web apps?
> >Of course, the best authentication system for banking I've seen is >from UBS. They send you a scratchlist of around 100 numbers. Every >time you login you use one of the numbers and cross it off. Very >slick. Does that really work in practice? That sounds really annoying. Is this for business banking or for retail? How do they get the next 100 numbers to the user? Do they mail it out when they've used 90? It sounds like it would be less annoying to use certificates and some plug-in token there is going to be that much extra work to deal with a password sheet.
Re: kylix: rad!
At 06:16 AM 1/14/2002, brian moseley wrote: >On Sun, 13 Jan 2002, Sam Tregar wrote: > > > On Sat, 12 Jan 2002, Perrin Harkins wrote: > > > > > Well, does this product actually have any users to compete for? GUI > > > builders usually don't work for anything but the most trivial websites > > > that could be written in anything and do fine. People seem to come to > > > mod_perl because they need more performance or more control than they > > > can get from CGI. > > > > Agree. > >you know, i think it's this attitude, or a more insidious >version of it, that keeps mod_perl from being as ubiquitous >as php. it's like having to pledge the frat before you can >get the hot chicks. i, for one, would like to see more >people getting interested in making it easy for people who >don't practice black magic to take advantage of mod_perl. OK, I learned mod_perl, now where are my hot chicks! :) 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. I guess there is PerlRun (but it's not true cleanup) or PerlRestart, but that's really slow To some degree, the nature of mod_perl "feels like" it makes it harder. A UI would help though especially if it had a debugger that learned when attached to a given httpd process what variables were being preserved and reused over and over again... so you could trace those things down. 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 R&D 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. 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... Later, Gunther
Re: Fast template system
At 05:05 AM 12/31/2001, Ryan Thompson wrote: >I've looked at TT (and have heard it's praises sung), but it requires >Perl 5.6.0, which is, unfortunately, not yet stable on all of the >production systems my projects are deployed on. The syntax and >features look about right, though... So it is something I might try >when 5.6.0 is more widely deployed. When did it switch it's position? I am using a version of TT from a few months ago but on 5.00503 quite nicely.
Re: transient object data
At 03:33 PM 12/23/2001, brian moseley wrote: >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? By attribute do you mean an element of the data structure that is blessed in the object? Or do you mean some sort of new attribute you would assign a new Serializable data type (ala something to suggest for Perl 6). Actually I think I was suggesting multiple inheritence as the 3rd mechanism. But I think it is fairly mandatory that the Transient object be an attribute or element of the data structure hash or array. Because not only objects should be serializable with transient elements, but so should general data structures I suspect. This is not so in Java so much, but definitely in Perl with it's more flexible ideas of what constitutes a data structure vs object then serialization needs to be equally flexible I suspect. Of course, this brings us back to the discussion of what a Perl bean would be like and how different it should be from Java. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Cache::Cache locking
At 10:55 PM 12/22/2001, brian moseley wrote: >Apache::Singleton::Server got me thinking about Cache::Cache >and locking again. if i'm going to have a server-global >object, i am going to need to protect against multiple >processes updating it simultaneously, right? > >we've already talked about this in regards to sessions. most >folks seem to feel that "last one wins" is sufficient for >session data. but what about for objects for which this >policy is not good enough? > >if locking is necessary in some instances, even if we can >only contrive theoretical examples right now, how might it >be done in a performant way, especially for objects that can >be modified multiple times while handling a single request? >seems like if you synchronized write access to the object >and caused each process to update its local copy after each >modification, you'd have a hell of a lot of serialization >and deserialization going on in each request. > >thoughts? Well, I think it depends on the situation. In Extropia::Session what we did was set up policies. The default policy is similar to Apache::Session. But we allow stronger policies if another application requiring more stringent care on the session data shares the user session handle and underlying data store. We ended up separating the concept into two seperate policies: a cache policy and a lock policy. Cache policies are things like no cache, cache reads, cache reads and writes (so nothing gets written until the object is destroyed or flushed manually). Lock policies include no locking (last wins), data store (the whole cache is locked because attributes may depend on each other), and attribute level locking (integrity is only maintained on the attribute write level). These "policies" effect a general policy of how Extropia::Session works. I think there are more sophisticated ways of doing an API than an arbitrary policy of course. In some cases, locking is something that should be settable directly. For example, I mentioned some attributes may depend on each other. For example, let's say a session stores an attribute indicating your savings account and another indicating your checking account. Obviously to perform a funds transfer within your session you'd want to wrap both attribute changes inside of a lock. Of course, this sort of lock can be separate from the session cache. But ideally in order to interact well with previously set session policies the locking that is automatic should be similar to the locking that is explicit. I think if I had to do it over, I would probably not have implemented my own Session and reused one of the newer caching mechanisms. One of the reasons I didn't go with Apache::Session is that I needed more sophistication than Apache::Session provided but I did like Apache::Session enough that we wrap around it and provide the extra session features I wanted. Later, Gunther
Re: transient object data
At 10:19 PM 12/22/2001, DeWitt Clinton wrote: >On Sat, Dec 22, 2001 at 06:11:33AM -0800, 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? > >I'd love that as well. For example, when persisting Cache::Object >instances I manually strip out transient (in this case, it is >re-creatable) data such as the name of the key and the size of the >object, in order to save space in storage. > >Sounds like Perl 6 needs a generic notion of Serializable. I think that is fine for Perl 6, but what do we do now? I think implementation wise it seems that there are several ways to serialize objects in Perl. So the natural thing to do is come up with some "meta data" standard that perhaps all the various authors (Data::Dumper, Storable, etc) like and use efficiently. I think an object of type Transient seems OK. Then, to make an element of a Perl data structure transient, you would add another element to that data structure of type Transient. If the data structure is an array, then the value of the Transient object should be an array of index numbers related to values that are supposed to be Transient. If the data structure is a hash, then the value of the Transient object should be an array of key names related to the values that are supposed to be Transient. If the data structure is an object, you would alternatively look and see if @ISA Transient, if it is a transient (through multiple inheritence) then that object type would never get serialized. Would this cover most general cases? So should this be a thread on p5ee or on mod_perl? :) Later, Gunther
Re: [OT] Re: Seeking Legal help
At 01:34 AM 11/23/2001, Mark Maunder wrote: >Matt Sergeant wrote: > > > Step three: Once you've given them 90 days after date of invoice, get a > > solicitor (not a barrister) to draft a threatening letter. It'll cost you > > about $100. I'm afraid you'll have to give them another 30 days at this > > point. > > > > Step four: Get a lawyer. Sue. $25,000 is not to be sniffed at. > >What many small companies and one man operations dont realise is that debt >collecting is an art. Also, some large companies (large banks in particular) >have a policy of 'If you want to do business with us, we take 60 days to pay. >It's all about keeping the cashflow on their side. It depends on the company, I think most take a long time to pay the first time because it's the first time you are being entered into their computer systems, contracts get signed off completely etc.. Of the large companies (banks included) we work with this is normally the case (a 60-100 day to get paid the first time), but subsequent times are usually quite easy for us as most of our large customers repeat back to us and we are already in their system for getting paid by their accounts payable department. Of course, there are exceptions to the rules, but I don't see large companies just arbitrarily trying to pull a longer cycle. At the least, they do usually have to wait for the accounts payable cycle and cutting an out of cycle check is a pain in the ass, but that comes sooner than 60 days. I think 60 days etc is reasonable if you are on a 1M-2M contract, but if your contract is a few hundred K over a year, it hardly will make that much of a collective cash flow dent to warrant it being worth their policy. By the way, if you are really working for a bank and cashflow is an issue for you in 60 days you can also ask the bank what business banking services they offer. One popular service with small businesses who have large companies working for them is invoice factoring which allows you to sell your invoice (if your company passes a credit check) to the bank for something like 80% of the face value of the account and then when the bank collects the invoice you get the rest minus interest and commissions. It's unlikely that they would grant the same credit with a 1-man company though. And I think they don't like dealing with service businesses. It's usually more for dealing with suppliers with real inventory where the main thing that can go wrong with an invoice is a pricing dispute over a line item of widgets I suspect. The other thing is that if you do a contract, build in billing cycles. 20-30% up front on a fixed fee contract is not unreasonable. Of course, you may need to commence work anyway before getting it if they are a large company that is having trouble getting you in their system, but that is the risk. But in any case, you can soon usually figure out whether they are going ot be paying your schedule or not. If you are just a normal hours-based contractor, then it's a bit more like getting a salary and so I think it is much harder to argue to be paid up front. >I did some work for a certain Linux distributor in the UK recently and they >took 100 days to pay after much harrasment. If you're small you have to be >tough - put the geek aside and become that vicious old lady that is usually >hired to badger late payers. The same all over the world. ;) Later, Gunther
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
One important thing THERE IS ALREADY A P5EE MAILING LIST GUYS!! :) So basically if you want to add your feedback, go there! It's already done but it's not too late to add feedback. :) email ... [EMAIL PROTECTED] At 08:36 AM 10/29/2001, Medi Montaseri wrote: >Similarly, this concept of Enterprise is a bugus idea ... from a pure >computer science point of view, there is no such thing as an Enterprise. >This is all Microsoft's branding trying to associate themselves with >something big, and Sun is stupidly following it "A pure computer science point of view"... Well, very few things exist from a "pure" computer science point of view because it's based on low level algorithms typically. However, that does not mean models that encapsulate the complexity of all the algorithms put together in certain ways do not have or add value. The concept of the enterprise is a very real model of interpreting the world of IT and how to distinguish between a localized, single-protocol systems and an enterprise system. Enterprise being a Microsoft Branding term? I don't think believe that it came before Sun. Sun and Microsoft are not branding themselves the same way. And I believe that the term enterprise has been around for quite some years independent of Microsoft. However, because of the Java and Sun branding of J2EE, it is important that Perl and other languages come together to say how they fit the enterprise as well. Why is this important? Credibility. While it's true that many businesses do not require "enterprise" solutions, a business can feel more comfortable adopting a solution if they know that it can grow with them. For example, if I were to download a public domain web store, I would much prefer knowing that the ecommerce solution were used by Amazon.com because then I'd know that if my "ReeferOnline" store were to take off in Columbia, that it would scale and I wouldn't have to look for an alternative solution. Also, the fact that a larger corporation can use the application means that they've worked out security and other issues better than I, a small IT arm of a huge Drug Overlord, can afford the time and effort to check out. While not everyone may need these additional reassurances from a marketing point of view, the majority of the world does. >My vote is to come up with something more pure than trendy like >Enterprise. My vote is that anyone who doesn't like a name should be the first person to come up with an alternative idea rather than just negating it and asking for others to come up with the hard work of coming up with something different. :) Anyway, please do visit the P5EE list. There is also an archive of past posts so you can play catch up from the last week. http://archive.develooper.com/p5ee%40perl.org/
[OT] excellent modperl/etoys article by Perrin revisited
I saw an article in today's ComputerWorld that indicates the technology et al for eToys was bought by another toy firm (KB) and they plan to put it up to sell toys for this holiday season again. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO65008,00.html Perrin or others involved in the old eToys (or anyone in the new eToys) -- does anyone know if this is the same mod_perl technology you guys wrote? I think it will make an interesting success story follow up if it is successful because it would also show how easy it was for the intellectual property written in mod_perl to be resold and reintegrated into another IT infrastructure which would make VCs happy (ie they would think more about being able to fund projects based on mod_perl if they know they could always resell the IP). Thanks, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 03:38 AM 10/24/2001, Stephen Adkins wrote:
>At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote:
> >Stephen Adkins wrote:
> >
> >> If no one suggests an appropriate list, I propose starting a "p2ee" group
> >
> >
> >Can I just say that P2EE is a horrible, horrible name? It includes the
> >Java version number (when is J3EE coming out?), as well as Sun's
> >desperate attempt to make it sound like something you buy ("Edition")
> >rather than simply a collection of APIs.
> >
> >Something simple, like Perl Enterprise Project or Perl Enterprise APIs
> >makes more sense to me.
>
>Hi,
>
>Several of you have made the same good point.
>And now the naming flame war has already begun... ;-)
>
>Unless there is violent opposition, the name will be
>
>Perl Enterprise Framework
>
>I would rather name it after the outcome (Framework)
>than the process (Project).
>
>The mailing list will be
>
>[EMAIL PROTECTED] (preferred)
>or
>[EMAIL PROTECTED] (in case Nathan already has it set up)
>
>If this seems reasonable, let's not flood the list with "ok with me"
>messages or "how about 'foo'?" messages.
>
>Stephen
I think this name and mailing list is excellent and much better than P2EE.
The mere fact that there is an endorsed perl.org mailing list for people
who wish to ask about enterprise issues (even without a specific standard)
is a huge step further in terms of making people aware that Perl CAN BE
used for the enterprise.
That is, there is a definite perception difference between
[EMAIL PROTECTED] and [EMAIL PROTECTED] [EMAIL PROTECTED] has a
perception of being endorsed as a place for a standard rather than just a
single couple of people's ideas on sourceforge.com (of which there are
thousands) and is likely to get more attention.
Re: Excellent article on Apache/mod_perl at eToys
At 10:36 PM 10/23/2001, Leon Brocard wrote: >Perrin Harkins sent the following bits through the ether: > > > Perhaps a port of JMS is in order. > >Interestingly, I've been thinking along the same lines. Spread >(http://www.spread.org/) can be used for the publish/subscribe >messaging domain but queueing seems to be important too. Straying a >bit offtopic perhaps, but I wonder what would be involved... One thing that would be interesting to me is an engine that can provide real time pricing feeds. It seems to me that jabber (chat engine) is actually a lot more powerful than being about chatting. Some applications are lonely and want instant messaging too. :) Queuing is important but for different reasons and usually different applications eg if your circuits are global. eg a London broker makes a transaction destined for Singapore, but has to go via Hong Kong and the London/HongKong circuit is only up every 5 minutes... Although this is not dissimilar to the resilience of a message delivered via SMTP relays.
Re: Excellent article on Apache/mod_perl at eToys
At 09:45 PM 10/23/2001, Perrin Harkins wrote: >Matt Sergeant wrote: > >>OK, so what are we missing? > > >Based on the comments I've seen here over the years, and some on Slashdot, >the thing that seems to worry people the most is the lack of an obvious >message queue API in Perl. I've seen plenty of implementations, but there >isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. I think it's more than that. It's more of a general all around 'feeling' as I've said before. It's about people and it's about the standards. The thing about "Enterprise" applications is that there are many components to what "enterprise" means J2EE compromises a lot of standards and frameworks all in one and to read the books about them all would take several weeks at least. But at least I know that when I read a book on EJB, I know this is the plan and it's stable etc... whereas someone's particular idea of a transaction engine in Perl is just someone's idea of a transaction engine in Perl. It may be a good idea, but it's really quite scary to build a large system around something that may not have a lot of success stories around it. This is why Perrin's article is so good. Because it starts getting more high profile success stories out there. There really are otherwise not that many about Perl when compared to Java. And even then, let's also consider the programming base. When I advertise for Perl programmers, they generally just know how to do Web apps and it's pulling teeth to even get OO and Mod_perl capability. It has to be taught after such programmers are brought in. But with Java, it's quite rare to find a Java programmer that hasn't programmed at least their own minimal RMI server before. I have little doubt that this is because of the sheer amount of documentation for making an RMI server plus the fact that it is a true "standard" so people feel comfortable that it is supported in a large community. Remember that my email said, I "feel" better about coding middleware in Java than in Perl. Just as I "feel" better about coding front-end in Perl. This is a "feeling" and isn't necessarily something that can be quantified -- it is also about perception which is something that cannot be ignored. And part of it is about "soft" issues like knowing that I can find Java programmers at a dime a dozen who have done middleware coding before in Java. I think more success stories would help. I also think official endorsement by key members of the Perl community (eg Larry) would help certain projects. ie I believe SOAP::Lite is now the defacto standard SOAP Library for Perl that people would recommend anyone to use no? So why is it still SOAP::Lite and not moved and advocated into the SOAP namespace where it belongs and make it the defacto standard SOAP engine for Perl if it's proven itself? Of course, choice is part of what makes Perl fun. But fun isn't for everyone. eg when it comes to such niche libraries as middleware tools, it's not so fun to have choices if none of the choices are very easy to evaluate. It's much nicer for a programmer to be able to reliably choose a tool they feel is backed by a strong community beyond just the immediate few people who may have done X middleware for one project or group of projects for one company. I really would like to see a generally endorsed P2EE project which includes SOAP::Lite as an interoperable webservices engine, a messaging engine, and transaction engine. Authentication engine and Session engine would be quite useful to include as well. Oh and Moseley's (sp?) servlets in Perl project would be a cool one to include as well. That would make it compete pretty much head to head with J2EE. And then success stories on top of P2EE. Later, Gunther
Re: Excellent article on Apache/mod_perl at eToys
At 08:46 PM 10/23/2001, Rob Nagler wrote: > > is easier and more standardized, and well documented. But I "feel" like > > coding front-end web applications is much easier in Perl where the workflow > > bits change all the time. For this, I like using SOAP on the backend Java > > server and SOAP on the front-end Perl. > >I don't quite understand the difference between worflow in the front-end and >workflow in the back-end. They both change. The danger of making one part >of the system easier to change is that people tend to "cheat". They won't >put the business logic in the back-end if it takes twice as long. Yes, people can cheat. But generally the workflow that is most likely to change is the UI based workflow. UI isn't just about templates, it's a lot about how you go from one screen to the next, or not. Actually business logic is a bit of a misnomer because there is plenty of business logic in the front-end from your choice of fields to the javascript to the UI workflow. >To me, the major issue in Perl vs Java is dynamic vs static typing. Building >large scale systems in Perl is much like building them in Smalltalk or Lisp. >It takes a certain mindset. The lack of compiled interfaces means you need >much more discipline (e.g. unit testing). The payoff is big with Perl, >because >you can refactor more easily and quickly than in Java. I don't think refactoring in Perl is necessarily faster. Actually, it can be quite hard to refactor in Perl as well but for the opposite reason. If you do not have a strongly typed system, then when you break apart and rebuild another part of the system, Perl may very well not complain when a subtle bug comes up because of the fact that it is not strongly typed. Whereas Java will complain quite often and usually early with compile time checking. Compile time checking can definitely be a friend of yours especially when dealing with large systems. But it's also a friend that's judgemental (strongly typed) so he's a pain to drag along to a party In practice, I still think using a good framework, it's about as long to develop in Perl as it is in Java for a medium sized system. My only beef I have with Java and I still have it is that the debugging support is simply atrocious for web apps. Perl has many more debugging utilities and allows much greater introspection. When I develop in Java, the only reason it takes me about 20% longer is that I am restarting the server much more often than I do in Perl. >The libraries aren't much an issue. A good example is SOAP. SOAP is >middleware. It is standardized, documented, and the rest of it. You like >it for connecting Perl to Java, but why can't it be the other way around? >If it can be the other way around, why aren't Perl and Java equally adapted >to building middleware applications? Java's support for multi-threading makes writing servers feel fairly trivial with no jumping through IPC::Shared memory stuff hoops to get shared memory caches and the like.. you just synchronize on global data structures. Arguably, an overuse of threads has problems in itself, but in general, I think it is easier. It is also easier to find programmers who know how to code middleware that do Java and harder to find people who have coded middleware that are Perl programmers... so maybe the language would support it, but there is also a personnel issue. Later, Gunther
RE: Excellent article on Apache/mod_perl at eToys
At 09:14 AM 10/23/2001, Robert Koberg wrote: > > For comparions, a nice aspect of j2ee applications IMHO is the > > "application server" tends to be more general. ie. the application > > server is not just the web server (as it is with mod_perl). I've found > > j2ee features such as message beans, queues and such especially useful > > for back-end work. For these reasons, I personally don't buy the > > argument that mod_perl makes an effective application server for a good > > sized task (your mileage will vary no doubt ;).> > > >What is stopping you from using both, if you want? It's generally quite tough to convince management that maintaining two sets of knowledge -- Java and Perl is cost effective. I suppose it depends on the size of the organization but "consolidation" of "standards" in an organization is an age-old thing (eg move all servers to NT, move everyone to Java, etc...) Whether this actually saves costs is a bit of an arguement probably not best for this mailing list. However, I would have to say that I "feel" like coding middleware in Java is easier and more standardized, and well documented. But I "feel" like coding front-end web applications is much easier in Perl where the workflow bits change all the time. For this, I like using SOAP on the backend Java server and SOAP on the front-end Perl. YMMV. And I don't know that many organizations which will allow such a heterogeneous environment unless a vendor installs it as a turnkey solution and is willing to deal with all the support. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Excellent article on Apache/mod_perl at eToys
Yeah we really enjoyed it over here. I think it's really excellent to get great advocacy articles about Perl and surrounding products (mod_perl, TT, etc) powering real businesses with real high powered needs out there like this one. :) At 04:40 PM 10/19/2001, Greg Cope wrote: >Andrew Ho wrote: > > > > Hello, > > > > I checked the list archives and it didn't look like this had been > posted yet. > > For those of you who haven't seen it yet... a great read on perl.com about > > the Apache/mod_perl setup at eToys, co-authored by our own mod_perl > > regular contributer Perrin Harkins. > > > > http://www.perl.com/pub/a/2001/10/17/etoys.html > > > >Yup, this is an excellent read. Thanks Perrin. > >Greg __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Mod_perl component based architecture
At 01:28 PM 10/17/01, Ilya Martynov wrote: > >>>>> On Tue, 16 Oct 2001 22:07:47 -0500 (CDT), Dave Rolsky > <[EMAIL PROTECTED]> said: > >DR> On Wed, 17 Oct 2001, Gunther Birznieks wrote: > >> I would venture to say that some of the mod_perl-only toolkits have some > >> cases of being better designed than ours, but they are mostly mod_perl > >> only. In fact, I don't know if I know any other toolkits than ours that > >> are not mod_perl only of the ones that were advertised on the list. > >DR> I don't know if Mason counts as a full toolkit (its not really an app >DR> server) but you can certainly run Mason as a vanilla CGI, and if you can >DR> do that I'm sure you can run it in FastCGI and whatnot. > >Moreover I have seen it being used in command line tool which >generates static HTML pages from a set of templates. Well so is Template Toolkit but it's still basically a content management/template engine not really an application framework. It's possible that Mason has applications written in Mason, just as you could write applications in ActiveServerPage or Cold Fusion pages, but that doesn't make ASP or Cold Fusion an Application Framework either. Or at least not a balanced MVC one. Open Interact, Smart Worker, and ours do not handle templating at all. We integrate with other packages to do that sort of management. We have frameworks that handle application logic in a fairly consistent way and this is what is meant by app framework (as opposed to template framework). Of course, I am not saying that the line isn't fuzzy especially if the template engine is quite powerful (as is the case with Mason or AxKit). But there is a line nonetheless, no?? Later, Gunther
Re: Mod_perl component based architecture
At 11:13 PM 10/16/01, Dominique Quatravaux wrote: > > also does modperl support object oriented programming? > > Well yes it does indeed (see any good book on Perl, such as >«advanced Perl programming» from O'Reilly). > > As for the remaining of the question, I've been wondering for myself if >there is a MVC (model-view-controller) framework for WWW publishing in >Perl ? I gather there exist quite a few for Java, but I couldn't find >anything significant under Perl. Our eXtropia toolkit is just about the only one out there that caters to all CGI environments with MVC architecture (action objects and action manager for controller, normal DB objects for model, and template toolkit for view)... If you go to http://www.extropia.com/ you can download any Perl WebDB app, WebCal, or WebBBS to see an example. We are still in a mode where we are distributing apps built around the framework rather than the framework itself but you can get the idea. WebDB in particular has a lot of documentation itself for free. If you are really interested in toolkit docs, we have an 800 page book out by McGraw-Hill whose later half 400 pages discusses in raw detail the architecture of the toolkit itself and how all the pieces fit together. One of the sad things is that the intelligent people on this list tend to have their head a bit in the ground when it comes to alternative environments other than mod_perl. mod_perl's a great tool but there's a lot of other Perl environments out there not the least of which is just plain old CGI. This is why our toolkit specifically caters to all. The other thing is that many (although not all) Perl people tend to have their head in the ground related to dealing with other environments such as Java. Our toolkit also plugs into Java environments. For example, we have a completely interoperaple Perl <-> Java persistence layer (via SOAP) if you wish to use a Java driver for a Perl front-end. We also spent considerable time porting our toolkit and several apps to Java MVC framework so we have Java Servlet/JSP equivalents of everything. Yet another thing is that many Perl people also have their head in the ground about Win32 compatibility. We've strived to make sure our entire toolkit will work reasonably well on Win98 and Win2000. A toolkit that only works on mod_perl will by definition not work well on Win2000 except as a toy because Win32 mod_perl is a single blocking thread. Great for development, not so great for production (unless the site is really small). I would venture to say that some of the mod_perl-only toolkits have some cases of being better designed than ours, but they are mostly mod_perl only. In fact, I don't know if I know any other toolkits than ours that are not mod_perl only of the ones that were advertised on the list. Of course, this may be what you are looking for. But since you mentioned Perl MVC and not specifically mod_perl-only MVC, I figured I would jump in and mention the alternative since we are much more open to alternative environments and not being closed in to just mod_perl. Later, Gunther
Re: Catching user-presses-stop early
Would sending a null byte work with a reverse proxy method of mod_perl if
the reverse proxy caches and doesn't deliver the data right away? I don't
know if there is a way to control this or what the behavior is.
As an aside, why not just send whitespace instead of a nullbyte? It's
supposed to be ignored anyway unless you are sending binary data.
At 06:35 AM 10/13/2001, Jeremy Howard wrote:
>Our site is suddenly getting to the point where resource constraints are
>becoming an issue for the first time. So, apologies in advance if I have
>lots of optimization-related questions over the next couple of weeks...
>
>One thing I would like to catch is the related problems of:
> - Users pressing stop in the middle of a long process
> - Users double-clicking rather than single-clicking links
>(resulting in 2 processes handling the request)
>
>I've read the 'user-pressed-stop' bit of the Guide (thanks Stas!) and
>although I think I understand the issues now, I'm looking for practical
>advice on approaches people use. I'm thinking that I should try writing a
>null byte to the client:
> - At the beginning of the handler
> - Every few iterations of potentially long loops
> - Before creating large files to send to the client.
>
>If I do this then Apache should receive the signal that the client has gone
>away, and should terminate the process happily (as long as I clean up
>properly, of course).
>
>So, does this sound like the right approach? Any way to simplify this to
>avoid explicitly adding print-a-null-byte lines to every loop? I'm wondering
>whether it's possible to add an alarm() and SIG{ALRM} handler or something
>like that, which sends a null byte every second or 2. Anyone using something
>like this successfully? Any potential problems from sending a null byte to a
>client?
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: [OT] What hourly rate to charge for programming?
C'mon guys remember to add OT to your off topic messages! It's not that hard. :) 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. >Work is scarce in Australia and poorly paid in most cases compared to >America. If I could get US$20 per hour for programming work I would be >overjoyed with that! > >I'm not experienced in mod_perl commercially so I doubt I would get more >than that, but I think US$20 per hour is reasonable for quality labor >nontheless. > >I need to work from home. Anybody got any suggestions? I have looked on >Yahoo for work from home jobs and they seem to be crooks. I never get any >responses. There's part of your problem. Few people trust telecommuters they don't know unless the job is fairly clear. I know I don't. I have telecommuters working for us on occasion but I know them or I trust them based on knowing them through a third party. You're lucky you get what you get and the price you get it. You're cutting yourself down of opportunities by having to work at home. I don't mean to be so frank about it. But really... this is a huge factor. It's a great luxury to work at home but it rarely works out unless you are really highly motivated or highly disciplined. Some people are like that, unfortunately this is not the majority of people so adding the project management overhead on behalf of the client means having to drop the hourly wage to the work-at-home consultant.
Re: [VOT] What hourly rate to charge for programming?
Hey guys..MASSIVELY OFF TOPIC!! :( :( :( At 12:24 AM 10/3/2001 -0400, Michael Bacarella wrote: > > I've had about two years of experience with perl, and one year of > > experience with mod_perl and MySQL. > > > > I've been doing contract programming jobs for people and charged by the > > hour. The rate I currently charge them ($40) was kind of chosen randomly. > > I'd like to find out if this figure is too high/too low. Does anyone here > > have any experiences to share? > >Contract programming is entirely different from salaried work. > >Assuming you live in the United States and are charging US dollars, >Consider: > > Taxes (including an additional self-employment tax). > > Insurance (health, general liability, and possibly others) > > (Home) Office Expenses -- stuff you use to generate invoices, > stuff you > use to do your actual work if done in your home, rent, etc. > > Continued education -- consultants are expected to be experts. > > Greater risk. You generally will also never work as much as > you'd like to. > > Your clients also get to wash their hands of you completely. Your > expenses are a direct tax writeoff, rather than an additional > accounting headache. > > >After deducting all of the above, a $40/hr rate starts looking more like >an $18/hr rate, and maybe even less. Consultants don't _just_ bill >$100/hr because they're scam artists. :) It depends on your location of course. I notice that Michael is in Manhattan which is a pretty expensive salary area of the USA. And it also depends on how long you are on a contract -- 6 months? A year at a time? or just a week or two to solve a specialized problem? >You're charging effectively half of what a salaried perl/mysql hacker >costs. Humility is a valuable business trait, but I'm positive you're >worth more than you're charging. Maybe.
Re: [ANNOUNCE] TicketMaster.com sponsors mod_perl development
At 01:28 AM 9/21/2001 +0800, Stas Bekman wrote: >If you remember back in the end of April, I've posted to the list an >unusual job seek request [1], where I was saying that I want some >company to sponsor me to work full time on mod_perl 2.0 development. > >Believe it or not my unusual request has been answered by Craig McLane >from TicketMaster.com (which owns citysearch.com). > >citysearch.com is a heavy user of mod_perl technology and interested in >making sure that mod_perl technology get more and more mature and ensure >their business' success. > >So starting from this September I'm working on mod_perl 2.0 >development, a new documentation project (which you are welcome to >join) and doing mod_perl advocacy through teaching at the conferences >and other ways. "You can reach your goals. I'm living proof. beefcake. BEEFCAKE!!" -- Eric Cartman Congratulations to Stas! >Currently the contract is for one year. But if everything goes well, >and mod_perl 2.0 rocks the world even better than 1.x did we will see >more support and sponsoring from TicketMaster. > >This email's purpose: > >- is to set a precedent for other business to sponsor mod_perl and > related technologies. There are at least a few excellent developers > that I know will jump on the opportunity of being able to do what > they love full time. > >- is to set a precedent for other developers to seek what they really > want and read less stories about hi-tech recession, since good > developers are always in demand. Therefore I hope that this email > will encourage you to do that. > >Notes: > > [1] http://forum.swarthmore.edu/epigone/modperl/runvesay > >_ >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/ > __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [OT] compilers for c Appache modules
I've never done it, but you may want to look for instructions on compiling mod_perl in general on win32. Likely however your mod_perl was compiled is a reasonable way to compile another C module on Apache for Win32. At 10:49 PM 8/19/2001 +1000, Rod Butcher wrote: >I know it's offtopic, please direct me to correct data source, can't find >it... >For the first time I need to compile a module (mod_throttle_access) for >Apache on Win32. >I have the free Borland 5.5 C++ command line compiler. What settings etc ? >(Have the Eagle book, can't find it there). >thanks. Rod >=== >This email message may contain the Ebola virus. >The sender is not responsible for any death, destruction, >reflux or tinitis that may result from reading this message. >The sender's lawyer forces him to write this crap. ______ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Path Issue mod_perl vs cgi-bin?
At 09:20 AM 8/17/2001 -0500, Purcell, Scott wrote: >Hello, >I am running Apache w/mod_perl on a NT box. Location = D:/Apache >I have created some modules and put the modules in a folder >D:/Apache/vb_modules >I set my PATH on the NT box to look in D:/Apache/vb_modules and all is good >when I use those modules under mod_perl folder. > >But today, I have the need to write some normal non-mod_perl files so I put >a file in cgi-bin >D:/Apache/cgi-bin and did a require module; >But for some unknown reason, it says it cannot locate my modules? > >Why is it that the mod_perl folder has no issues and the cgi-bin directory >cannot find my modules > >I have never seen anything like this. Does anyone have any ideas? > >Is there some config I need to set up in the cgi-bin directory? I don't think so. Note that Apache recognizes the first line of the script and will attempt to resolve Perl in that location. eg #!/usr/bin/perl is resolved by default ( I think ) to c:\usr\bin\perl.exe So you may wish to be truly explicit and use #!c:\perl\bin\perl.exe Instead... (You may have to escape the \ but I forget). >Thanks, > > >Scott Purcell __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: my() [very off topic]
It is not off topic if you realize that the way Apache::Registry and PerlRun wraps scripts will cause the closures to occur with my. So it's really rude to actually have anew person have to join an entirely new mailing list just because of a problem that mod_perl itself forces the user to deal with and partially is the cause of. It seems to me that he is confused about when the variable will not stay shared or will which is a direct result of using shared programming. Although I don't know what he is confused about because I thought the guide explains it OK? Later, Gunther At 01:37 PM 8/14/2001 -0700, Dave Baker wrote: >On Tue, 14 Aug 2001, swade wrote: > > > Much thanks! What do the knowledgable programmers do? Do they my() thier > > variables, etc at the beginning of thier subroutines? Or do they do it as > > they come to it? or is it really just personal prefence? > > > >This is rather off topic for mod_perl and should (imho) belong on a perl >list instead. Can I request any followups be taken to private mail or a >more suitable list? > >Thanks, > >Dave __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Augmenting CPAN with P2EE specs, was CPAN polution
At 12:10 PM 8/11/2001 -0400, Stephen Adkins wrote: >Hi, > >At 04:42 PM 8/11/2001 +0200, Elizabeth Mattijsen wrote: > >At 09:26 AM 8/11/01 -0500, Jim Smith wrote: > >>If we want better QA, I'd propose requiring approval from someone on that > >>list before a module is put anywhere in the heirarchy other than the > >>author's directory instead of only requiring approval for a top-level > >>namespace. > > > >Are you aware of the CPANTS initiative? Michael Schwern gave an > >interesting talk about that at the YAPC::Europe. See e.g. > > > > http:[EMAIL PROTECTED]/msg00148.html > > > >I like the idea of CPANTS, karma, kwalitee, etc. >However, another approach is similar to what J2EE did to Java. >There were lots of libraries/packages growing up in Java, and the >J2EE spec said "these versions of these API's make up a consistent, >extensive, useful, architecturally sound platform on which to build >applications". > >What about the concept of a P2EE specification? >(P2EE is pronounced "pitooey", as in "I spit on the notion that >Java is the only language for enterprise-capable web application >development". It is also pronounced "pee-two-ee-ee" when managers >are around and you want to convince them it is a legit technology >for your next project.) >(I also note that "p2ee.org" is not yet taken as a domain.) The idea behind P2EE is not precisely new. Larry Wall addressed it in his State of the Onion speech this year. Basically Perl 6 is the rewrite and he realized the standard distro of modules is really both bloated and too sparse at the same time. So what may make sense is bundling stuff in the same way that Java does. So in Java you have the standard SDK library of class files but you also have the J2EE bundle. >We all know that there will never be a single P2EE specification. >This is because there will be those who think that one template system/ >data persistence layer/XML Library/etc., combination is better than another. > >However, individual perl gurus could pull together their list of >consistent, complementary, and quality API's/modules (and how to >use them) in a spec and call it their vision of P2EE. > >This would be very valuable to those just getting started. >They understand that There's More Than One Way To Do It >(tmtowtdi), but at least they can survey how various perl gurus have >integrated the many different technologies before them and learn >at least One Good Way To Do It from each spec. > >This method of competing P2EE visions > > * is decentralized and dynamic (not centralized and unchanging), > * is merit-centric (P2EE visions will wax and wane based on merit), and > * provides a way that individual modules can rise above the crowd. > >I can envision that module authors would work with the leading P2EE spec >authors to ensure that their modules fit into the vision. If the P2EE >spec authors like the modules, they get included in that particular spec. >In this way individual modules are naturally subjected to a certain form >of peer-review in order to qualify for a spec. In return, the visibility >of the module is increased because of the spec. If someone doesn't like >the existing P2EE specs, they can create their own. > >Perhaps the various P2EE specs could be supported on CPAN with Bundles. > >I also think it would be *much* easier to rate/rank P2EE specs than >individual modules on CPAN. (i.e. this goal is attainable with a finite >amount of effort) > >Thoughts? > >Stephen I think this is reasonable. Items for definite inclusion would be POE and SOAP::Lite. I hesitate to include templating systems or application toolkits. Although Caching (Cache::Cache, IPC, etc) could also fall under P2EE I think. Later, Gunther
Re: odd behavior with Cache::Cache
At 05:44 PM 8/5/2001 -0400, Perrin Harkins wrote: >on 8/4/01 1:34 PM, brian moseley at [EMAIL PROTECTED] wrote: > > 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. > >Gunther's Extropia stuff includes optional support for sessions that lock in >the way you're describing, but I've never seen any other session >implementation that did it this way. It seems that the session pattern is >generally used for transient data where last-save-wins is fine as long as >the integrity of the data is protected during the actual writes. If you >need fancier locking, you could try ripping the lock stuff out of >Apache::Session. > >- Perrin My impression was that the locking in Apache::Session is a one-time lock so it just fixes data integrity issues. So I am not sure if it is fancier than Cache::Cache unless Cache::Cache has no locking at all (or no concept of lock choice). I was really interested in abstracting the locking API for Extropia::Session because it was an interesting challenge and frankly at the time I *thought* that Apache::Session did it, so I wanted to match it. In addition, the motivation for Extropia::Session was to match the Java Servlet Session spec so I wanted to make sure that whatever protections were provided by Java, I would have in Perl multiprocessing environment. The latter being fairly difficult to emulate exactly. In the end, I don't think I have actually written any applications that would cause two session updates to occur at the same time, so it might have been overkill. I am lately thinking of session as a means to store very transient stuff but then real persistent application data such as cart data from a web store should be stored in a real data storage with real multi-user locking with the session id as a mere key to that database. I guess it just depends on your scenario. I would be curious to hear about some real world (as opposed to academic) scenarios about it being an issue. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
RE: Apache::DBI in startup.pl generating error
appearing earlier or later in a config file is significant is so common I'm
>astonished you consider it bad manners to see code that depends on it. And
>unless I'm very badly mistaken, it's even significant in httpd.conf as far
>as *Apache* is concerned.
>
>And secondly, you're right, this is *mod_perl*. Not IIS, NSAPI, PHP, or
>Cold Fusion. startup.pl is indubitably a mod_perl idiom. I'm failing to
>understand how this can be considered "portable". But if you mean portable
>from system to system, well, last I heard, ActiveState hadn't quite gotten
>signals or sockets mastered, but I'm pretty certain the have the %ENV
>emulation worked out.
>
>But thirdly, I consider it a convenience to be able to test a script for
>syntax errors before attempting to -HUP my webserver to see if it works or
>not. perl -wc is done almost before I register the cursor moving. apache
>restarts take me at least a minute. It's not about the request cycle, it's
>about the DEBUG cycle. Since I didn't write Apache::DBI, but I have
>reasonable confidence in the guy who did, it doesn't hurt my feelings to
>defer initializing it until I've finished modifying startup.pl for other
>reasons. Which means I can make a change, switch windows, and perl -wc and
>get a syntax check, instead of an Apache error on Apache::AuthDBI, in under
>10 seconds. Or even perl -w (even tho I run w/ -w in the shebang line and
>PerlWarn On) and see debug output I'm working with.
>
>For the record, I also consider it cheesy to have to check $ENV{MOD_PERL}
>but to my knowledge, the Apache $s object isn't passed to startup.pl, and
>setting an environment variable is significantly cheaper than creating a
>perl object in terms of C code and devel/debug time. Remember, the E in
>perl is for "Eclectic." :-)
>
>Idioms are there for a reason: They do well in shorthand a required task.
>Even if there are other, longer ways to do the same thing. TIMTOWTDI. The
>way I "ought to" program is in the way that makes perfect sense when one
>understands all of the pieces, and document the hell out of it so that
>people behind me who don't understand can at least follow the requirements
>list. ESPECIALLY when the person behind me is me, 6 months later.
>
>
>
>L8r,
>Rob
>
>#!/usr/bin/perl -w
>use Disclaimer qw/:standard/;
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: Apache::DBI in startup.pl generating error
Alternatively, you can remove use Apache; from Apache::DBI and then you can test it perflectly fine from the command-line, you just won't be able to use connect_on_init() which is the only reason Apache::DBI seems to load Apache.pm (Apache.pm is causing your problem not Apache::DBI). At 10:20 PM 8/2/2001 +0800, Stas Bekman wrote: >On Thu, 2 Aug 2001 [EMAIL PROTECTED] wrote: > > > Thanks to all (esp Stas) for helping me with the 'make test' error > > involving CGI.pm. Here is the next issue: > > > use Apache::DBI (); > > > When I run "perl -c startup.pl", I get the following error. I get NO > > error when I comment out the 'use Apache::DBI' line: > > > > Can't locate object method "module" via package "Apache" at > > /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm > > line 202. > > BEGIN failed--compilation aborted at startup.pl line 8. > > > > Is there an earlier version of Apache::DBI I should be using (like the > > CGI.pm error)? > >It's not a problem. Apache::DBI expects mod_perl env, and hence you cannot >test it from the command line. I suppose that you don't have a problem to >start the server with Apache::DBI loaded. > >It's documented somewhere is the guide too. > >_ >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/ __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: require v.s. do in modperl
At 07:18 PM 8/1/2001 -0700, Nick Tonkin wrote:
>On Wed, 1 Aug 2001, Philip Mak wrote:
>
> > I have a CGI application where I do:
> >
> > require 'db.pl';
> >
> > where db.pl defines some functions and variables related to connecting to
> > the database, and then executes C<$dbh = DBI->connect(...)>.
> >
> > I tried to convert this application to modperl, but I ran into the problem
> > that require did not execute db.pl again the second time I called the
> > script, so that the C<$dbh = DBI->connect(...)> line was not executed.
> >
> > I can get around this by changing C to C, but is that the
> > "correct" way of doing things? It seems a waste to redefine all the
> > subroutines and variables again. But I do need it to reinitialize $dbh
> > when C is called.
> >
> > What should I do?
>
>
>One of the things you should do that I have not yet seen mentioned is
>look into using Apache::DBI so you don't have it "reinitialize $dbh" on
>every request.
>
>If you do have multiple DBs in your application you can still used cached
>database handles; just name them differently.
But you should still call $dbh = connect() on every request so that
Apache::DBI's magic can truly work??
Otherwise ping tests and other such stuff will not work and you may as well
not use Apache::DBI at all and just use BEGIN { $dbh ||= connect() } which
of course, is probably not working well.
Re: require v.s. do in modperl
At 07:16 PM 8/1/2001 -0400, Perrin Harkins wrote: > > I have a CGI application where I do: > > > > require 'db.pl'; > > > > where db.pl defines some functions and variables related to connecting to > > the database, and then executes C<$dbh = DBI->connect(...)>. > > > > > I can get around this by changing C to C, but is that the > > "correct" way of doing things? > >No. Put the connect stuff in a subroutine and call it from your >application. Things in the main section of a required file are only >supposed to run once. I am not sure, but I don't think connect() is only supposed to run once especially with Apache::DBI?
Re: require v.s. do in modperl
For what you are trying to do, you should turn it into a module. Sorry for the short post, I've gotta split... Although it's not user friendly, my more constructive hint is to type perldoc perlmod to get a quick tutorial on writing a module. At 06:56 PM 8/1/2001 -0400, Philip Mak wrote: >I have a CGI application where I do: > >require 'db.pl'; > >where db.pl defines some functions and variables related to connecting to >the database, and then executes C<$dbh = DBI->connect(...)>. > >I tried to convert this application to modperl, but I ran into the problem >that require did not execute db.pl again the second time I called the >script, so that the C<$dbh = DBI->connect(...)> line was not executed. > >I can get around this by changing C to C, but is that the >"correct" way of doing things? It seems a waste to redefine all the >subroutines and variables again. But I do need it to reinitialize $dbh >when C is called. > >What should I do? __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Not embedding SQL in perl (was RE: [OT] Inspired by closing comments from the UBB thread.)
At 02:44 PM 8/1/2001 -0700, Jeffrey W. Baker wrote: >On Thu, 2 Aug 2001, Gunther Birznieks wrote: > > > When you've had your fill of wrestling over mySQL vs PostGres and stored > > procs versus inline SQL (I know I have long ago) > > > > You guys should definitely read the following: > > > > http://www.ambysoft.com/persistenceLayer.html > > > > One of my current coworkers turned me on to this. I have found it to be one > > of the best series of articles related towards what it takes to abstract > > database away from your object layer and the various levels at which it > > makes sense to do so. > > > > You may find the design a little complex, but Scott pretty explicitly > > states that this is what is necessary for a *large* system. You can always > > go down a less complex path by choice if you feel your programs aren't > > complex enough to need the full Persistence Layer structure he advocates. > >I've worked with Scott Ambler, and I could record everything Scott Ambler >knows about actually devleloping large systems on the head of a pin, using >a magic marker. That guy is a hopeless academic without the slightest >clue of how to actually make software happen. I suppose I can't comment on your opinion as I do not personally know him. But I find his statements to be worthy (as explained further below) regardless of what you say about his real-world knowledge. So I can only imagine that he has taken in many comments from users over the years and made up his articles based on feedback since I think this one is particular is reasonable. Although I've never had to implement all 6 or so object abstractions in the ultimate persistence layer he recommends. :) >Here's the brutal truth about persistance "abstractions" using an RDBMS >backing store. At some point, your DBA is going to come up to you and >tell you that you code is too slow. You need to rewrite some SQL queries >to use a different index, or some sorting hints, or whatever. You will >realize that you need to pass some extra information down through your >abstraction layers to make it all happen. After that happens twice or >thrice, you will slowly come to realize that your abstraction is really no >abstraction at all: every time the schema changes, the top level interface >needs to change as well. I can't say that I agree. It depends on what you are coding for. Are you coding for performance or are you coding for getting a product out there that is easy to maintain? In many cases, these two requirements are quite at odds. This thread was originally sparked by someone getting annoyed that SQL was embedded throughout the code and finding it hard to grasp how to deal with this. While it's true that the best performance comes from hand-coding the SQL, and if you hand-code the SQL, it should arguably be close to the section of code that requires this SQL, not all programs require this. In fact, very few in my experience. Those that have required speed have required it for a small subset of operations in a larger project. I strongly believe many apps can get away without having SQL embedded. I've been doing it for the last several years and definitely coding and maintenance time improves with some persistence layer abstraction. But yes, you run the risk of having to go back and code a SQL statement or two, and you run the risk of somewhat lower performance, but as Scott mentions in his article, these should be the well-documented exception, not the rule. Nick Tonkin posted a very clear and well written post a few minutes ago about embedding SQL close to the code which may demonstrate the opposite of what I am trying to say. But on the other hand, I could understand that a company such as ValueClick really have to make sure their databases and the SQL that accesses them are completely tweaked. So I think given speed requirements, making a HERE document and using other clean-coding techniques to keep the SQL close to the code that needs it is quite reasonable. However, in my experience... Of the things that are harder to duplicate in a persistence layer to one degree or another... Not all applications require transactions Not all applications require aggregation beyond count Not all applications require blinding speed (just decent speed) Not all applications require joins Not all applications require unions Not all applications require subselects And even if you would argue that taking into account a union of probabilities an application may need at least one of the above, I have found it simply is not true. Usually when an application has a fairly complex data model then they need more than one of the above and that's when you have to move to SQL. In other words, if the probability that an app needs e
Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections
At 01:19 AM 7/26/2001 +0200, Issac Goldstand wrote: [snipped] >I see what you mean. I'm not dealing with client certs (yet), and I'm >thinking that when the system that I'm testing now goes production, it'll be >a front-end SSL, back-end non-SSL sorta deal... But that won't work for now >due to other security issues on the developments boxes... [snipped] >I understand that. It's just not doable for this... In actuality, the >"back-end" server now is not REALLY back-end... The mod_perl server is >_behind_ that, so I'm really doing what you're suggesting already :) > >However, information must still get to this "middle-level" server, and the >top level server certainly can't be trusted to decode sensitive >information... Considering this issue, it seems that what might help you more is a VPN. Have you tried using SSH port forwarding for the time being? And just allow the SSL stuff to go from your external web server directly through an SSH vpn link to the back-end (your true front end) server. Later, Gunther
Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections
At 07:05 PM 7/25/2001 +0200, Issac Goldstand wrote: > > The front end server must be configured to understand SSL. Otherwise, how > > else can the HTTP request be pulled apart (decrypted) to understand that >it > > has to be forwarded to the backend server. > >2 words: dumb proxy. The request doesn't need to be pulled apart by the >front-end server in this case. The entire virtualhost is supposed to be >tunneled directly to the back-end server. That's what I'm trying to figure >out how to do... I see. I don't know if that will work. The connect header is a special proxy feature to allow a proxy to just pass through all the TCP level packets instead of opening a separate SSL client connection. But from a reverse proxy perspective, I am not sure that mod_proxy is automatically given this special header by the browser as it might if you configured IE or Netscape to use a physical proxy server. But it definitely won't work based on the HTTP Hostname parameter because SSL has to be established before any other HTTP header other than the weird connect one is decoded. > > If you configure the back-end server to understand SSL, that's OK, but > > beware that all mod_proxy is doing is establishing one SSL connection from > > browser to mod_proxy and then a brand new SSL connection from mod_proxy to > > the backend server. 2 separate SSL sessions because SSL cannot (ie > > inconvenient to) be man-in-the-middled. > >I know that. The key is (and must be) on the back-end server. Which is why >I'm trying to do it this way. The mod_perl book seemed to imply that this >was possible, and I _know_ that mod_proxy is supposed to recognize CONNECT >requests for this very purpose - it says so in the manual... I just don't >know how to set it up properly... > > > It has some likelihood to also to be inefficient because I am not entirely > > sure that mod_proxy is caching the SSL client session key that it >generates > > to connect to the back-end server as the browser normally does for the > > front end. > >I'm not even sure that mod_proxy can be it's own SSL client... The >documentation says it knows how to handle incoming CONNECTS, but I'm not >sure that it could make its own HTTPS request... If you try it, I think you will find that this works. If you compile in mod_ssl, mod_proxy can establish SSL connections to the back-end. The only thing you lose other than performance is the capability of passing a PKI certificate through the proxy (since decoding and establishing a new SSL connection would be considered a man-in-the-middle attack). When you don't care about client certificates, it really doesn't matter that the reverse proxy is in the middle because the reverse proxy has the valid server certificate that your client is pre-programmed to understand is a valid certificate (eg from Verisign). Really, the cleanest way of doing what you want is to run the SSL engine on the front-end and then proxy (convert) back the connection to the backend as HTTP. If you are using some authentication on the front-end (eg client certificates) there are modules which will allow you to take a USER_DN and pass it to the back-end server as an addition parameter (eg using mod_rewrite) or as another custom HTTP header. > Issac > > > At 03:26 PM 7/25/2001 +0200, Issac Goldstand wrote: > > >I am trying to make a back-end mod_perl/mod_ssl server. The front-end > > >server that is currently in place is doing a great job forwarding normal > > >requests to the back-end, but it is not forwarding SSL. Now, the >front-end > > >server does not understand SSL, itself. What I'm doing is trying to >force > > >the entire VirtualHost listening on port 443 to an IP on a private subnet >on > > >an obscure port (what I do for all the back-end servers. There are >actually > > >3 of them doing various things). But it won't work. The strange thing >is > > >that if I go to http://mysite:443/ I get the default Apache "It Worked" > > >page, but https://mysite/ generates an error saying that the front end > > >cannot understand, which seems to be pointing at the fact that it's not > > >forwarding ANYTHING to the back-end server... > > > > > >Stas & Eric: This situation is mentioned in your book, but in nowhere >enough > > >detail. IMHO, that segment of the book (near the end of chapter "Server > > >Setup Strategies for the Best Performance") should be redone in better > > >detail to explain forwarding SSL to the back-end server. > > > > > > Issac > > > > > >Internet is a wonderful mecha
Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections
The front end server must be configured to understand SSL. Otherwise, how else can the HTTP request be pulled apart (decrypted) to understand that it has to be forwarded to the backend server. If you configure the back-end server to understand SSL, that's OK, but beware that all mod_proxy is doing is establishing one SSL connection from browser to mod_proxy and then a brand new SSL connection from mod_proxy to the backend server. 2 separate SSL sessions because SSL cannot (ie inconvenient to) be man-in-the-middled. It has some likelihood to also to be inefficient because I am not entirely sure that mod_proxy is caching the SSL client session key that it generates to connect to the back-end server as the browser normally does for the front end. At 03:26 PM 7/25/2001 +0200, Issac Goldstand wrote: >I am trying to make a back-end mod_perl/mod_ssl server. The front-end >server that is currently in place is doing a great job forwarding normal >requests to the back-end, but it is not forwarding SSL. Now, the front-end >server does not understand SSL, itself. What I'm doing is trying to force >the entire VirtualHost listening on port 443 to an IP on a private subnet on >an obscure port (what I do for all the back-end servers. There are actually >3 of them doing various things). But it won't work. The strange thing is >that if I go to http://mysite:443/ I get the default Apache "It Worked" >page, but https://mysite/ generates an error saying that the front end >cannot understand, which seems to be pointing at the fact that it's not >forwarding ANYTHING to the back-end server... > >Stas & Eric: This situation is mentioned in your book, but in nowhere enough >detail. IMHO, that segment of the book (near the end of chapter "Server >Setup Strategies for the Best Performance") should be redone in better >detail to explain forwarding SSL to the back-end server. > > Issac > >Internet is a wonderful mechanism for making a fool of >yourself in front of a very large audience. > --Anonymous > >Moving the mouse won't get you into trouble... Clicking it might. > --Anonymous > >PGP Key 0xE0FA561B - Fingerprint: >7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [ANNOUNCE] RoboWeb 1.0b, web application test suite generator
If you guys end up finally collaborating, one very minor request I would have is that it goes into CPAN as something more standard like WWW:: namespace rather than a marketing name like RoboWeb. RoboWeb is actually a good product name (and in fact do a search on google for other tools with a RoboWeb label attached to them), but it really opens up room for misinterpretation in the future. And personally, I think these seem like indispensable tools that should be a standard CPAN addition. Calling it RoboWeb on CPAN will make it as confusing as figuring out which template solution to use -- but I suspect that web testing features can be fairly standardized (unlike templates). At 11:53 AM 7/23/2001 +0400, Ilya Martynov wrote: > >> We should investigate how these 2 projects can work together when I'm > >> done so that RoboWeb 'recorded' sessions can create WWW::Automate methods > >> that utilise the structure of the page. The benefits of doing this are: > >> 1- Resultant scripts are easier to interpret > >> 2- Scripting apps that vary their form field names works. > >CG> [..skip..] > >CG> I look forward to seeing WWW::Automate and to working together on this. > >I've recently become maintainer of another testing module >HTTP::WebTest. Stable version (released on CPAN) already has many >interesting features (like response time tests, text matching tests, >content size checks, support for both remote web server and local test >modes). I'm working on its rewrite in modular style where tests >modules are pluggable so it will be easily extendable. After finishing >with it I thought about writhing proxy that records users actions and >produces skeleton of test. > >Maybe joining our efforts have some sense. > >-- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >| Ilya Martynov (http://martynov.org/)| >| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | >| AGAVA Software Company (http://www.agava.com/) | > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: cgi-lib.pl
Rather than go into the details, it's probably best that you use Apache::PerlRun in place of Apache::Registry. cgi-lib.pl is an old Perl 4 library, if you are using new Perl 5 features like OO, modularity, and want to take the MOST advantage of mod_perl, use CGI.pm instead. CGI.pm also has a backwards compatible mode for cgi-lib.pl scripts. Also please read the mod_perl guide. http://perl.apache.org/guide/ At 01:03 AM 7/24/2001 -0500, John Buwa wrote: >Hello, > >I have a huge system i wrote using the cgi-lib.pl as its core. I attempted >to integrate mod-perl with my system and all my cgi-lib.pl which are used >via a require in all scripts returns errors. My dont work, if they do the >act very strange and unacceptable. > >My question is how do i use cgi-lib.pl and mod-perl together? Is anyone >doing this? How can it be done. > >Here is a common error in my log: > >[Mon Jul 23 05:38:06 2001] [error] Undefined subroutine >&Apache::ROOTwww_2emy_2ddomain_2ecom::cgi_2dbin::pads::welcome_2epl::ReadPar >se called at /driveb/usr/web/webroot/cgi-bin/pads/welcome.pl line 7. > > >Any info would be appreciated! > >John __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: OT: Re: ApacheCon Dublin Cancelled?
At 10:46 AM 7/16/2001 -0600, you wrote: >Matt Sergeant writes: > > I doubt it's the last one we'll see fall... I suspect TPC will be a > > shadow of its former self... :( > >for four years arguing that it should be cheaper. If you feel that >there'd be more attendees at a lower price, then I suggest you tell >that to every O'Reilly conferences person you see at TPC (except for >me :-) > >Are there any requests other than price for next year? What would you >like to see? What could you do without? I'd like to know more about suggestions to make these suggestions? Is it really as simple as me going to another O'Reilly person or filling out an apres-conference survey form and saying "More attendees for less money". Or is there anything more concrete that would help it more? I am just afraid that simply stating this, I would not be taken seriously because it seems so obvious. But how do you get more attendees? Will they definitely come if it is less money? And if so, how much less? I am not a marketing person, so I am really bad at figuring out how to map this concretely, but I am not sure that there is an obvious price point where someone would attend or not attend. For example, let's say the conference costs $1000 and 1000 attendees attend? At that point it is $1,000,000 to hold the conference. And let's just say that's what you need to pull it off. But if you lower the cost by 10% to $900, then you've lost $100,000. So you need at least another 120 or so attendees to make up the cost. But will you get more attendees? Although you lowered the price by 10%, the hotel and the plane remain a fixed cost. Let's say it is $1000 for the hotel and $500 for the plane? Then a 10% drop a $1000 conference fee becomes less than a 5% drop in the overall cost and no more attendees may actually come. Anyway, here are some suggestions I would personally have to make it easier to attend conferences like this. Although perhaps they have already been thought about in the past and discarded for good reasons by people who know more about conference organization than I do... :) Note that some ideas are more radical than others and reflect that I am just shooting some ideas out. 1) More Student Discount (If none already) I don't know if this is currently the case, but I think people who are true full-time students should be allowed to attend at a significantly reduced cost. Part of open source and Perl advocacy is getting the young generation hyped so that they will want to continue to carry the torch. My gut feeling is that full-time students don't tend to attend these expensive conferences anyway because it's their parent's that they would have to convince. So offering them a low enough ticket cost to basically cover expenses will still contribute to the bottom line yet get a new round of attendees. And next year they may be out of school with a full time job that would be willing to pay for them. So it primes a set of attendees to continue attending. 2) I found the hotel costs really high. A good chunk of the entire cost of going to the conference is the hotel. I think Nat posted on this list, alternatives which was great. But I actually wish I knew the alternatives before I had signed up. I emailed someone directly in the beginning asking for alternatives because I come from Singapore where the currency is much less than your US currency, but did not get any alternatives. Since I didn't know the area and don't have a travel agent I trust to really know the hotel geography relative to the conference, I just reached out of my ass and paid the high cost of being in THE conference hotel. Of course, I do prefer to be at the conference hotel because it's more fun to be close to the action, it would have been nice to have been given a choice. I know that you guys probably get a lot of discount from Sheraton by having them be the only hotel on the listed on the Web for the conference, but it isn't at all convenient for conference attendees. Why should each attendee manually call another travel agent to find out alternative hotel costs (and not all travel agents REALLY know the area well) individually when OReilly could be posting alternatives. After all, you guys actually walked around the area and scouted out for facilities and probably know what the hotel and conference situation is truly like better than many travel agents sitting in their big office buildings taking calls all day. I just think that if you could provide a hotel that is like 3/4 the price then you make the entire package (Hotel, Flight, Conference fee) that much more attractive WITHOUT lowering the cost of the conference itself. If sponsorship of the hotel is a problem, maybe they would be OK with a link at the bottom that says "Cheap People Click Here". And it would take you to a page that explains the true alternatives for the area if you can't afford to be in THE hotel. That would certainly h
Re: OT: Re: ApacheCon Dublin Cancelled?
At 11:31 AM 7/16/2001 -0700, Bill Moseley wrote: >At 10:46 AM 07/16/01 -0600, Nathan Torkington wrote: > >Are there any requests other than price for next year? What would you > >like to see? What could you do without? > >Well, this is more along the "price" issue that you don't want to hear about, >but I much prefer a single fee for everything instead of separate tutorial >and conference fees. I understand the scheduling hell, but I like the >flexibility to decide what to attend during the conference. What I attend >in the morning may influence what I attend in the afternoon. I am misunderstanding this perhaps. Don't you get this anyway by getting a slightly larger discount for taking the tutorial and the conference together? ie is that what you are asking for? To combine the fees so that it is cheaper? >And these days more and more people may find themselves like me, paying >their own way. I'm very disappointed that I had to cancel after adding >everything up. In today's economy it's perhaps true. In the economy of 2 years ago, it seems like a business would consider it a perk to send their developer to a conference because they were scrambling to keep their programmers anyway they could (conferences is one way if their organization won't allow a raise in salary). But now many programmers are fortunate to have a job. Although there are still pockets of companies willing to pay for conferences, it's probably quite lower. Well, at least if you want a cheap conference there is always YAPC. I would suspect the O'Reilly brand unfortunately probably prevents doing things that involve having a truly on-the-cheap conference. Of course, by cheap I don't mean "bad". Just a different way of handling a conference and a different vibe/level of coordination and # of talks etc... Later, Gunther
Re: BOF?
At 12:10 AM 7/16/2001 -0500, James G Smith wrote: >Matt Sergeant <[EMAIL PROTECTED]> wrote: > >On Sat, 14 Jul 2001, brian moseley wrote: > > > >> 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. > > > >Judging by where the hotel is, I think probably the hotel bar is going to > >be best. I arrive on Sunday. > >As do I. Just let me know where and when. I will be in around 1pm on Sunday for those that want to do a late lunch. I think that Philippe and Stas will be around also. Definitely night time drinks would be great on opening night...
RE: BOF?
At 01:19 PM 7/14/2001 -0400, Geoffrey Young wrote: > >-Original Message- > >From: Ken Williams > >To: modperl > >Sent: 7/14/01 11:48 AM > >Subject: BOF? > > > >Yo, > > > >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. > >I thought Gunther was in charge this time > >;) Ah... I thought I was just looking into the T-Shirts. :) Anyway, the T-Shirts aren't a go this time anyway because of a lack of someone to pay for them. I'd like to have sponsored but we're paying (to various degrees) for 3 people to attend the conference this year so that didn't work out either. If you like, I guess I could try organizing to get a BOF room? The only mod_perl BOF I attended was last ApacheCon which was by the pool with drinks. I think that was very nice. :) I wonder if we can reserve the pool and drinks being brought to us for the BOF this year instead a stuffy room. :) Is there a reason for actually getting a mod_perl BOF room? ie are there announcements to make that wouldn't be made at Doug's 2.0 talk or through the mod_perl track? Or would it just be a place to gather before finally heading off someplace else? Later, Gunther PS I am in DC all week on vacation before the conference so I can probably help out a bit.
OT: Re: ApacheCon Dublin Cancelled?
At 03:44 PM 7/15/2001 +0100, Matt Sergeant wrote: >Looks like Camelot, the organisers of ApacheCon (and other conferences, >such as XML Dev Con - a conference I've spoken at a number of times), are >going out of business. Those of you who know the employees at Camelot will Odd, I got the letter for ApacheCon speakers talking about payment to speakers which I would think you got as well. >know they always went out of their way to help the speakers at various >conferences, and I would venture to say they were one of the better >organised conferences I've attended. Sad to see them go. I too am sad. I did not know the conference producers well, but I personally thought the plane + hotel + conference fee paid to all speakers EVEN 1 HOUR talk speakers was really generous. I can usually understand paying those things for tutorial speakers, but giving all that for 1 hour talk speakers was amazingly generous though. But I guess too generous. Anyway, lately conference attendence is down, so naturally vendors don't want to spend a lot of money on advertising at a conference, so naturally there's less money to pay for speakers, so naturally less people want to attend with less speakers, etc I hope the downward trend doesn't continue with other good conferences. :(
Re: Apache::SimpleTemplate
At 06:16 PM 7/7/2001 -0700, brian moseley wrote: >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 ;) I think it is still quite difficult. Even if you have servlets, for example, adding JSPs was quite a task. At issue is providing a minimal API yet still allow the templates to do things that weren't originally intended. In addition one of the criteria for "useful" to me is "fast". If the template system is slow, it's quite annoying. However, this goes against other people's ideas of "useful" being "full featured". As Steven Wright says (paraphrased) if you had everything where would you put it? So to make something that is powerful yet fast is quite the challenge. And then there are architectural tradeoffs as to the type of application that the template is being used for. Transactions? Portal based? Integrating many apps together? Standalone? Later, Gunther
Re: rand bug?
Your problem is likely that the use of a global my is creating a closure
(see mod_perl guide). Replace it with use vars qw($rand); and don't declare
your globals using my.
At 01:07 PM 7/6/2001 -0500, Purcell, Scott wrote:
>Hello,
>
>rand bug with mod_perl?
>"my $rand = int(rand(1000)) always produces '2'" under mod_perl.
>I have noticed that if I ask for the line above, it always puts $rand at a
>'2'? So I did some test below, looping through and the first time through
>with mod_perl, the number is always 2?
>
>
>Under investigation when I run the following code under cgi-bin, it works
>good like it should.
>960 is tmp
>240 is tmp
>193 is tmp
>197 is tmp
>
>
>When I run that same code under mod_perl, it looks like this:
>2 is tmp
>564 is tmp
>194 is tmp
>809 is tmp
>
>So basically if I just need one random number I have to do some excess work?
>
>Does anyone know why this is?
>If anyone wants just drop the following line under cgi-bin and mod_perl and
>you'll see the results.
>
>Please let me know,
>Scott
>
>
>
>#! perl
>use CGI qw/:standard/;
>my $q = CGI->new;
>print $q->header();
>print $q->start_html("hello");
>foreach (my $i=1; $i<5; $i++) {
> my $tmp = int(rand(1000)+1);
> print "$tmp is tmp\n";
>}
>
>
>Scott Purcell
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: [OT]: Re: Just a few good men? Was: ignored (again)
At 06:35 PM 7/5/2001 -0500, Jimi Thompson wrote: >Gunther, > >I think that mentions in publications like Ziff-Davis, CMP.net, maybe >SysAdmin. However, the techies know mod_perl and love it. It's the PHB's >that we need to convince of the merit of our chosen platform. Therefore, >it also needs to make it into the rags that management reads like Forbes, >Barron, New York Times, etc. SO if anyone knows of any reporters for >these rags, we need to educate them so they can write a really good >article. And the articles need to keep coming. Then maybe the PHB's will >fall into line. > >Just an idea. The problem is that setting up a web site is not mainstream news. Nor is having an application server out. This is tech news and even then there are a lot of app servers and a lot of web apps out. You need to have some business angle. As a tech company, we deal with this all the time -- how do we get ourselves in the press? Our technology may be cool, but it's not really news-worthy in either Perl or Java. So we get ourselves in the press by aligning ourselves with jobs that may have news-worthy significance. For example... http://asia.internet.com/asia-news/article/0,3916,161_793941,00.html An article that is about a new type of service that hasn't been offered before in Malaysia. But with enough twists to get our own name in the news in agreement with the client with whom we did the work when we were able to craft a press-release. So similarly, I think a key point is to get Perl news about how it affects real business bottom line. This is similar to a talk we gave at PerlCon two years ago about Perl in the investment banking community. And it was the primary purpose behind a book that I wrote a chapter for called Applied Perl. The idea is that it is a book with chapters written by all sorts of people from all types of backgrounds, writing about how they use Perl (plus source code!) in their specific businesses from investment banking to the entertainment industry to mobile phone computing. Anyway, I am really happy that a publisher took us up on the book (originally Peter Williams, myself, and Selena Sol were shopping it around and then Peter Williams took over as the editor (we wrote for it but declined editing due to lack of time)) because I think it continues to show more about how Perl pervades every industry and walk of life. AND as a shameless plug, if the book is purchased enough, perhaps they'll want a follow-up which will advertise Perl even more. As a disclaimer, I make no money on additional sales of the book, I just wrote the chapter for a flat rate. :) > >Jimi >>----- Original Message - >>From: <mailto:[EMAIL PROTECTED]>Gunther Birznieks >>To: <mailto:[EMAIL PROTECTED]>Matt Sergeant ; >><mailto:[EMAIL PROTECTED]>Joachim Zobel >>Cc: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED] >>Sent: Thursday, July 05, 2001 6:24 AM >>Subject: [OT]: Re: Just a few good men? Was: ignored (again) >> >>At 07:44 AM 7/5/2001 +, Matt Sergeant wrote: >> >On 04 Jul 2001 17:31:24 +0200, Joachim Zobel wrote: >> > > >> > > Hi. >> > > >> > > The question is: Are a few good developers all we need? If this is the >> > case >> > > we can safely ignore to be ignored (we have them). >> > > >> > > It is OK to be one of the few people to know the leading Apache >> > development >> > > system. But it has serious drawbacks. Where I work people are migrating >> > > from server side javascript to java. With better Perl marketing they >> might >> > > migrate from Perl/CGI to mod_perl and my work would be more fun (I do >> > > consider changing my >> > > job an option, but I like the people I work with). It is however >> > > frustrating to leave work, get on the tram, take out my laptop and do it >> > > better than I did the 8h before. >> > > >> > > So do we want to be "Enterprise" and "Industry Standard" and such crap? >> > >> > >> >Yes, we do. But I don't think it's enough to convince people to move to >> >"mod_perl". They want to move to a better framework. I'm sure you know >> >which one I favour :-) Sadly most people *still* see Perl on the web as >> >CGI, as printing out your HTML from code, etc. It needs more articles in >> >the right places to fix that sort of misconception. >> > >> >Matt. >> >>This is really off topic. >> >>Anyway, so what are the right places for those articles? Microsoft Systems >>Journal? :) >> >>And what should we do to get the articles in the right places? >> >> >>__ >>Gunther Birznieks >>(<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]) >>eXtropia - The Open Web Technology Company >><http://www.eXtropia.com/>http://www.eXtropia.com/ > >__ >Gunther Birznieks ([EMAIL PROTECTED]) >eXtropia - The Open Web Technology Company >http://www.eXtropia.com/
Re: Apache V2 and Mod_Perl Question
At 04:46 PM 7/5/2001 -0500, Purcell, Scott wrote: >Hello, >NT question. >I believe that Apache 2 is out for NT, and was wondering if apache 2 works >with mod_perl? I am running Apache 1.3.20 and mod_perl 1.25_01-dev. Can or >should we start converting to Apache 2? > >Just curous about some time frames for this. > >Thanks > >Scott Purcell Apache 2.0 is still in beta and could be for a long time. mod_perl 2.0 will be in alpha/beta until Apache 2.0 is actually released and I am not aware of a timeframe for Apache 2.0 being released. Although perhaps it's possible that someone else knows something about Apache 2.0 timelines getting solidified. Like the release of the Linux kernels, I suspect the answer to the schedule is that it will be released when it's ready. :)
[OT]: Re: Just a few good men? Was: ignored (again)
At 07:44 AM 7/5/2001 +, Matt Sergeant wrote: >On 04 Jul 2001 17:31:24 +0200, Joachim Zobel wrote: > > > > Hi. > > > > The question is: Are a few good developers all we need? If this is the > case > > we can safely ignore to be ignored (we have them). > > > > It is OK to be one of the few people to know the leading Apache > development > > system. But it has serious drawbacks. Where I work people are migrating > > from server side javascript to java. With better Perl marketing they might > > migrate from Perl/CGI to mod_perl and my work would be more fun (I do > > consider changing my > > job an option, but I like the people I work with). It is however > > frustrating to leave work, get on the tram, take out my laptop and do it > > better than I did the 8h before. > > > > So do we want to be "Enterprise" and "Industry Standard" and such crap? > > >Yes, we do. But I don't think it's enough to convince people to move to >"mod_perl". They want to move to a better framework. I'm sure you know >which one I favour :-) Sadly most people *still* see Perl on the web as >CGI, as printing out your HTML from code, etc. It needs more articles in >the right places to fix that sort of misconception. > >Matt. This is really off topic. Anyway, so what are the right places for those articles? Microsoft Systems Journal? :) And what should we do to get the articles in the right places? __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: SSL and thin/fat server setups.
At 02:07 PM 6/29/2001 -0500, Christopher L. Everett wrote: >Hello all, > >I've been running apache+mod_perl servers with apache+mod_ssl >front-ends, and been quite happy with this type of setup for >quite some time. > >Now I need to use SSL certificates for authenticating users >of an online database. It seems like there's no way to get >the SSL information that the front-end sees to the back-end >server because the SSL protocol underlies the HTTP protocol >(outside of writing a custom apache module, and passing back >the cert info in headers) and there's no such thing as an SSL >proxy module that I've been able to find. > >Right now, I'm considering setting up a very lightweight >apache+mod_perl+ssl+mod_proxy frontend with just a single >perl auth/authz handler installed, and have that decrypt, >authenticate, authorize, and proxy all SSL requests back >to the fat server. Then I revert the apache+mod_ssl front >end to a vanilla apache server and have it handle all >plain HTTP requests. >Before I do this, I'd just like to know if anyone has any >other ideas on how to do this. Read Mads post. We use a similar method of accomplishing this in our own work. You can't use mod_proxy to proxy the SSL connection to the back-end server because as soon as you've established the SSL connection from the front-end proxy to the browser, you can't carry the certificate through to the back-end server even if you establish a second SSL connection. You can only satisfy the SSL challenge response mechanisms through having the browser's private key which the reverse proxy does not have. Later, Gunther
Re: where to report apache::session 1.53 bug ?
Most of the time it is really bad to email open source authors directly. They released a piece of software out of kindness. But hey, it's open source and they can't hold up the entire world of support like an Atlas, 24x7. That's the job of open forums like this. So the author continues time to write new updates while the forums basically run themselves with other people sharing ideas and support. At 04:50 AM 6/28/01 +0700, Iwan Garnadi wrote: >I don't know where to report apache::session bug , because I sent to the >author , I didn't get any reply yet ______ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: mod_perl bof Oreilly Conference TShirts
Apparently last year the quantity was 150 for US$10/shirt. This was a 2 color shirt. So the damage was US$1500. However, there are two factors that may lower the cost. One, perhaps not as many shirts have to produced because the conference attendence may be lower this year than last year (although I think the more TShirts the better!) ... So I'd rather this not be the case. And two, Randal has generously proposed using a contact of us that may be able to produce similar or better quality for as low as US$5/shirt. Of course, so that I do not raise expectations falsely, I will add that this may depend on quantity and it remains to be made into a concrete negotiation with the supplier for these additional shirts. So if the cost actually did go down to half, the cost for 150 shirts would be US$750. Merely the cost of Windows 2000 Enterprise Edition. If a corporation out there can spend money on a proprietary operating system, surely they can help sponsor a rag-tag bunch of misfits on a mission to save the Earth... oh, sorry, got carried away while watching the SciFi channel... Later, Gunther At 03:49 PM 6/19/01 -0700, James wrote: >What's the qty? What's the price? > >James. > > > Jimi Thompson wrote: > > > > Gunther, > > > > We are still interested in doing the design. If a corporate sponsor > for the > > printing will step forward, we'd be happy to work their logo into the > design. > > > > Jimi > > > > - Original Message - > > From: Gunther Birznieks > > To: mod_perl list > > Sent: Saturday, June 16, 2001 10:17 AM > > Subject: mod_perl bof Oreilly Conference TShirts > > > > A month ago I posed a question about TShirts for mod_perl BOF. > > > > One group of people did volunteer to do the design and posted > > interest on > > here. So if they are still up for it, it would be awesome to start > > discussing ideas/proof of concept. > > > > However, before such a thing can be discussed, unfortunately no one > > has > > come up to be able to sponsor the cost for the T-Shirts. So I figure > > I > > would raise the question again in case someone has a company that > > would be > > willing to corporate sponsor such a thing. > > > > ______ > > Gunther Birznieks ([EMAIL PROTECTED]) > > eXtropia - The Open Web Technology Company > > http://www.eXtropia.com/ __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Forking Child 2
heh...I see your confusion (and everyone else's) There's no such thing as httpd -X on Windows. It's one server that's multi-threaded. A completely differnet model to UNIX. You don't have to do httpd -X because mod_perl on Windows Apache is kind of crippled anyway. It will ONLY run with one perl interpreter with serialized access to it. So you are already experiencing the equivalent of debug mode (httpd -X) when you run on Apache for Windows. No extra work necessary. At 09:45 AM 6/18/01 -0500, Purcell, Scott wrote: >Hello, >I wrote a little bit ago about trying to not fork my Apache server. I want >to run only a single child. Anyway, I got three terrific responses, but have >no clue what they mean. > >I am on Apache NT4.0 and am learning. Anyway, some of the responses I got >for setting a single process were: >type: >/path/to/apache/dir/httpd -X > >I have been through my install trying to execute a httpd at the command >line, but I am making no connection. > >Could someone please explain a litle more in detail what I should do on a NT >system and what the httpd is (exe?); > >Thanks > >Scott Purcell __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Advanced daemon allocation
At 02:29 PM 6/18/2001 +0800, Trevor Phillips wrote: >Gunther Birznieks wrote: > > >I suppose I could do this now by having a front-end proxy, and mini-Apache > > >configs for each "group" I want, but that seems to be going too far > (at this > > >stage), especially if the functionality already exists to do this > within the > > >one server. > >To me, this isn't very ideal. Even sharing most of an apache configuration >file, what is the overhead of running a separate server? And can multiple I think this is covered in the guide. >Apache servers share writing to the same log files? Why would you need to? The front end can write the log file. Then don't bother logging the mod_perl servers. Or make them all log to syslog or some other shared logging mechanism. >It also doesn't help if I have dozens of possible groupings - running >dozens of >slightly different Apache's doesn't seem a clean solution. Hence me asking if >it was possible within the one Apache server to prioritise the allocation to >specific daemons, based on some criteria, which would be a more efficient and >dynamic solution, if it's possible. It's not ideal, but it's also not possible to do what you say until mod_perl 2.0. You might also consider using Speedy::CGI if you aren't using handlers as it makes the multiple configs issue much more trivial to administer, but you still get a pretty fast speed up.
Re: Advanced daemon allocation
Yeah, just use the mod_proxy model and then proxy to different mod_perl backend servers based on the URL itself. At 01:17 PM 6/18/2001 +0800, Trevor Phillips wrote: >Is there any way to control which daemon handles a certain request with apache >1.x? > >eg; Out of a pool of 50 daemons, restricting accesses to a certain mod_perl >application to 10 specific daemons would improve the efficiency of data cached >in those processes. > >If this is impossible in Apache 1.x, will it be possible in 2.x? I can really >see a more advanced model for allocation improving efficiency and performance. >Even if it isn't a hard-limit, but a preferential arrangement where, for >example, hits to a particular URL tend to go to the same daemon(s), this would >improve the efficiency of data cached within the daemon. > >I suppose I could do this now by having a front-end proxy, and mini-Apache >configs for each "group" I want, but that seems to be going too far (at this >stage), especially if the functionality already exists to do this within the >one server. > >-- >. Trevor Phillips - http://jurai.murdoch.edu.au/ . >: CWIS Systems Administrator - [EMAIL PROTECTED] : >| IT Services - Murdoch University | > >--- Member of the #SAS# & #CFC# < >| On nights such as this, evil deeds are done. And good deeds, of / >| course. But mostly evil, on the whole. / > \ -- (Terry Pratchett, Wyrd Sisters) / __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
mod_perl bof Oreilly Conference TShirts
A month ago I posed a question about TShirts for mod_perl BOF. One group of people did volunteer to do the design and posted interest on here. So if they are still up for it, it would be awesome to start discussing ideas/proof of concept. However, before such a thing can be discussed, unfortunately no one has come up to be able to sponsor the cost for the T-Shirts. So I figure I would raise the question again in case someone has a company that would be willing to corporate sponsor such a thing. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Questions Simple
It's pretty easy to get mod_perl running on Apache for windows because one of the list members regularly makes a full binary distro available of apache/mod_perl/perl all bundled together. I think there is a link from the perl.apache.org homepage but I am not sure. I've set it up before several times in the last couple years and each time it seems to get easier (not because I am familiar with it, but because the install seems to get better/more intuitive). At 12:25 PM 6/14/01 -0500, Purcell, Scott wrote: >Hello, >I am on IIS and fighting ActiveStates .plex. It appears so buggy and flaky >that I am losing development time. > >I want to try some code that is flaky on the IIS/perl .plex on the Apache >mod-perl. > >I know I can download the apache web server in binary form and install it >pretty quickly. After that what would I have to do to get mod-perl running? >Is this a quick thing, or a long deal. Then I just want to take my clean >code and see how it works on that platform. > >Is mod-perl just a perl module that I require in my scripts? Or is there a >lot of server configuration? > >Please be honest and let me know, >Scott Purcell ______ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [OT] Is this feasible in Perl??
My experience is that architecturally Perl cannot handle this. You should
switch to Java and use an Enterprise Java Bean to do all this for you.
My hint to you is use a hash where the key is a SSN# to help you. Of
course, your description of what you want to accomplish is quite ambiguous
so who knows whether this will really help you. But I notice you are
attempting to do a lot of stuff with arrays when I think hash would help.
Anyway, this isn't the place to post non mod_perl questions anyway. Please
find a normal Perl syntax mailing list please and do not clutter up this
list with Perl newbie questions -- this is a mod_perl list not a Perl
syntax list. Perl.com has links to a lot of these resources.
At 05:19 PM 6/12/01 -0400, F.H wrote:
>Hi All,
>I have a text file like this:
>
>Name ,123-43-4352, JX, 1234
>Sports,123-43-4352, SKI, BaseBall, swimming
>Hobbies, 123-43-4352, H1,H2, H3
>Hobbies, 123-43-4352, HH, HHH, 2
>Hobbies,123-43-4352, H1,H43
>
>Name ,223-63-9352, JX, 1234
>Sports,223-63-9352, SKI, BaseBall, swimming
>Hobbies, 223-63-9352, H1,H2, H3
>Hobbies, 223-63-9352, HH, HHH, 2
>Here is my issue, I am trying to access each record in this file by SSN
>ie: (223-63-9352)
>I want to be able to say:
>for SSN = 223-63-9352, for Hobbies4 4th entry is HGFR.
>
>while ($line = ){
>
>
> @line = &parse_line(',',0,$line);
> if ($line[0] =~ /^NAME/gi){
> $ssn = $line[1] ;
> push(@ssns, $ssn);
>
> }
>
> if ($line[0] =~ /^Sports/gi ){
>
> push(@sports, $line)
>
> }
>
> if ($line[0] =~ /^Hobbies/gi){
>
> push(@hobbies, $line)
>
>}
>
>for ($i = 0; $i<= $#ssns; $i ++)
> {
>print "For $ssns[$i]\n";
>
> for ($i = 0; $i <= $#Hobbies ; $i++){
>
>if ($Hobbies[$i] =~ $ssns[$i])
>{ print "Hobbies are: $Hobbies[$i]\n";}
>}
>
>
>I wanted to print out for each SSN corresponding SSN numbers but it's just
>not working!!! If this is feasible in Perl I'd appreciate if someone could
>help.
>
>
>Thanks
>I.S
>
>__
>Get your own FREE, personal Netscape Webmail account today at
>http://webmail.netscape.com/
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: Single Process Mode IIS
It's not the same as apache. to do the equivalent set your max perl engines in PerlEx to 1 and that will serve the same purpose. At 09:33 AM 6/11/01 -0500, Purcell, Scott wrote: >Hello, >I joined the modperl line because I am trying to work with persistent web >data. My problem is that I am forced into using PerlEx, which is basically >activestates mod-perl. If this offends anyone on this list, please let me >know. My hands are tired. I am a perl developer needing assistance. > >Anyway, I am going over the 'mod_perl_guide CGI to mod_perl Porting and >Coding Guidelines.' It is very helpful for anyone dealing with these issues. >But anyway, I want to run my IIS server on a single process so I can follow >the documentation. Does anyone out there know how to do that? > > >Sincerely, > >Scott Purcell __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: comparison of templating methods?
At 08:59 AM 6/8/2001 -0500, will trillich wrote: >On Fri, Jun 08, 2001 at 06:52:14PM +0800, Gunther Birznieks wrote: > > At 02:26 PM 6/7/2001 +1000, Steve Smith wrote: > > > > HTML::Embperl > > > > > >For me, this has one major win over the other toolkits: auto form > > >population from a hash. The online mortgage application system I > > >wrote has about 1,800 form fields, which have to be populated with > > >data from a database. By making the form fields match DB column > > >names, I can reduce the code to do this to: > > > > > >my $data = $dbh->fetchrow_hashref($query); > > >%fdat = (%fdat, %$data); > > > > > >Embperl then parses the form and populates it with the matching > > >name=>value pairs in %fdat, including select options. Beautiful! > > > > Not that it's a reality now, but this is one of the things that the Perl > > Widget Library project on source forge is hoping to accomplish for > template > > languages. It's a cross template way of organizing form information and > map > > it to db fields. > > > > The reality is that there are many fields that cannot map easily 1-1 to a > > database as you say. eg a date in a database is usually a date field. But > > in a form, it might be a combination of 3 form fields (dropdown for month, > > year and day separately). > >which of the existing paradigms will the widget farm most >closely resemble? and what are your expectations for tradeoff in >functionality/modularity-vs-performance? 1) What do you mean by your first question? 2) I believe there is nothing being done in the widget farm that would really hinder performance other than being objects with methods. Really without a good object structure then a widget farm is wholly useless. If you need extremely high performance pages than you probably need to code more low level than throwing abstractions around like widgets. Please read the following, and then take the conversation to the widget-specific mailing list if you are interested in talking more about it. http://www.officevision.com/pub/Widget/ Thanks, Gunther >-- >I figure: if a man's gonna gamble, may as well do it >without plowing. -- Bama Dillert, "Some Came Running" > >[EMAIL PROTECTED] >http://sourceforge.net/projects/newbiedoc -- we need your brain! >http://www.dontUthink.com/ -- your brain needs us! __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: comparison of templating methods?
At 08:25 PM 6/8/2001 +0200, Gerald Richter wrote: > > At 02:26 PM 6/7/2001 +1000, Steve Smith wrote: > > > > HTML::Embperl > > > > > >For me, this has one major win over the other toolkits: auto form > > >population from a hash. The online mortgage application system I > > >wrote has about 1,800 form fields, which have to be populated with > > >data from a database. By making the form fields match DB column > > >names, I can reduce the code to do this to: > > > > > >my $data = $dbh->fetchrow_hashref($query); > > >%fdat = (%fdat, %$data); > > > > > >Embperl then parses the form and populates it with the matching > > >name=>value pairs in %fdat, including select options. Beautiful! > > > > Not that it's a reality now, but this is one of the things that the Perl > > Widget Library project on source forge is hoping to accomplish for >template > > languages. It's a cross template way of organizing form information and >map > > it to db fields. > > > > The reality is that there are many fields that cannot map easily 1-1 to a > > database as you say. eg a date in a database is usually a date field. But > > in a form, it might be a combination of 3 form fields (dropdown for month, > > year and day separately). > > > >Such things could be solved by using DBIx::Recordset for database access and >define some filters, which are able to transform the content of a field >to/from format you need it. Well, that assumes everything is a database... "everything I think I see, looks like a database to me..." If you look at PHP's GPC model and then realize that it goes farther into allowing other datasources such as S or a DB or a secondary DB if the first one is empty for that field, then you'll see that abstracting it in a common way rather than a DBI-specific view is much more powerful and is something that applications do occasionally have to do. Writing a filter is doable but really kind of a hack really.
Re: comparison of templating methods?
At 02:26 PM 6/7/2001 +1000, Steve Smith wrote: > > HTML::Embperl > >For me, this has one major win over the other toolkits: auto form >population from a hash. The online mortgage application system I >wrote has about 1,800 form fields, which have to be populated with >data from a database. By making the form fields match DB column >names, I can reduce the code to do this to: > >my $data = $dbh->fetchrow_hashref($query); >%fdat = (%fdat, %$data); > >Embperl then parses the form and populates it with the matching >name=>value pairs in %fdat, including select options. Beautiful! Not that it's a reality now, but this is one of the things that the Perl Widget Library project on source forge is hoping to accomplish for template languages. It's a cross template way of organizing form information and map it to db fields. The reality is that there are many fields that cannot map easily 1-1 to a database as you say. eg a date in a database is usually a date field. But in a form, it might be a combination of 3 form fields (dropdown for month, year and day separately). Later, Gunther
Fwd: CFP DEADLINE for ApacheCon 2001 Europe is SATURDAY!
I didn't see mod_perl in the list... and since I like to see mod_perl talks
at ApacheCon, I figured I would forward this on. :)
>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>list-help: <mailto:[EMAIL PROTECTED]>
>list-unsubscribe: <mailto:[EMAIL PROTECTED]>
>list-post: <mailto:[EMAIL PROTECTED]>
>Delivered-To: mailing list [EMAIL PROTECTED]
>Delivered-To: moderator for [EMAIL PROTECTED]
>Date: Fri, 1 Jun 2001 10:34:18 -0400
>From: Rodent of Unusual Size <[EMAIL PROTECTED]>
>To: ApacheCon Announcements <[EMAIL PROTECTED]>,
> Apache Announcements <[EMAIL PROTECTED]>,
> Apache Developers <[EMAIL PROTECTED]>
>Subject: CFP DEADLINE for ApacheCon 2001 Europe is SATURDAY!
>User-Agent: Mutt/1.2.5i
>X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
>
>-BEGIN PGP SIGNED MESSAGE-
>
>
>
>Greetings!
>
>To-day is Friday, 1 June 2001, and to-morrow is the DEADLINE
>for proposing sessions for the ApacheCon 2001 Europe conference
>in Dublin in October 2001. That means you have less than
>TWO DAYS to finish procrastinating and submit that session
>you have been thinking about! :-D
>
>The call for participation system will close at 17:30 EDT on
>Saturday, 2 June 2001. Schedule planning will begin almost
>immediately, so there is NO chance of submitting late! :-)
>
>Speakers for scheduled sessions have their travel and lodging
>paid by the conference, as well as receiving a speaking fee.
>
>Only the session abstract is needed by to-morrow.
>Required information for presentations are the abstract,
>a copy of any slides/viewgraphs used ('session notes'), and
>a copy of a 'white paper' written version of the material (the
>'session handout'). The handout should enable someone who
>does *not* attend the session to get almost as much information
>as he would have if he *had* attended.
>
>To submit a session proposal, log on to the ApacheCon site at
>
> http://ApacheCon.Com/html/login.html
>
>If you do not already have an account, create one. Once you
>have logged in, choose the 'submit a CFP' link under the
>ApacheCon 2001 Europe heading.
>
>PLEASE be sure that your email address and biographical information
>are correct!
>
>Thanks! See you in Dublin!
>
>
>- --
>#kenP-)}
>
>Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
>Apache Software Foundation http://www.apache.org/
>"Apache Server for Dummies"http://Apache-Server.Com/
>"Apache Server Unleashed" http://ApacheUnleashed.Com/
>
>"All right everyone! Step away from the glowing hamburger!"
>
>-BEGIN PGP SIGNATURE-
>Version: PGPfreeware 5.0i for non-commercial use
>Charset: noconv
>
>iQCVAwUBOxenzJrNPMCpn3XdAQFE2AQAoA76OQnTGH8njngGQKnCAihCVCE8fqCv
>HpZ7Qq+6ORD4yXUiUxxaP6CAExjJPcu6hBz0SjsnMdN3TOhioLakThRFyANAqfN5
>SmnZjRECTCOXBmXucr9MVMFA2MX07a5byPmZqr9jQN1RSikyMJbv+ThfdLtFhKdn
>qZqqXFXMaSA=
>=4tKP
>-END PGP SIGNATURE-
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: Real Widgets and Template Languages
At 03:50 AM 6/1/01 +0200, Issac Goldstand wrote:
> > At 09:14 PM 5/31/01 +0200, Issac Goldstand wrote:
> > > > At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
> > > > >At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> > > > > >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
> > > > >...
> > >[...]
> > >
> > >Complex Widget:
> > >
> > >Y-Offset="20"
> > >TabStop="True" TabIndex="3" name="text1" value="some sample text"
> > >tooltip="Enter some text here"/>
> > >
> > >Now, let's say that the developer prints this with the HTML "Driver" -
>this
> > >could do something like:
> > > > >onMouseOut="Window.status=''"/>
> > >
> > >And in some other GTK-based environment, it could do something like:
> > >
> > >Label text1;
> > >with (text1)
> > >{
> > > .Length=50;
> > > .Width=25*XCharSize; // The *XCharSize would have to be defined by
>the
> > >driver or by the native interface
> > > .Height=1*YCharSize; // This would be a default setting "plugged in"
>by
> > >the driver
> > > .Value="some sample text";
> > > .Left=40;
> > > .Top=20;
> > > .TabStop=1;
> > > .TabIndex=2; // 3-1 for 0 based - also defined by the driver...
> > >}
> > >
> > >Now, neither of these cases used _all_ of the widget parameters - a
>simple
> > >HTML designer could have produced an IDENTICAL widget by doing:
> > >
> > >
> > >
> > >This shows a few things, actaully. First of all, the widget can get as
>many
> > >or few parameters as the developer wants to supply it with - extra
> > >parameters will be discarded by drivers who do not understand them, and
> > >missing parameters will be supplied with "default" values wherever
>possible.
> > >Now, I would suggest designing this such that the developer only
>interacts
> > >with a Widget::textbox. Internally, there would have to be a
> > >Widget::HTML::textbox and a Widget::GTK::textbox, each with the
>UI-specific
> > >rendering instructions...
> > >
> > >The only problem is making sure that the overhead is kept to a minimal -
>in
> > >that as few feautres that are not actually NEEDED for the specific
> > >implementation are loaded as possible (eg, a user using only certain
> > >elements in HTML will only load those elements, and only HTML, while if
>he
> > >wants WML, it will also incur WML generic overhead too). I think this
> > >approach should satisfy both the wants to keep the widgets as generic as
> > >possible, as well as Gunther's wanting to keep the widgets as simple and
> > >easy-to-use/understand as possible (for beginners, at least).
> >
> > While adding parameters to the constructor is not a problem, I guess I
>have
> > a problem with adding behaviors. If you believe that simply adding more
> > config hooks to allow XWindows to be supported is doable, then we should
> > just leave it as mentioning this as a supposition and leave it to you or
> > someone else to prove that the supposition works after v1.x of the widget
> > set is released.
> >
>
>For arguments sake, I suppose it can be left as a supposition (OK, so I'm
>too swamped just now to do a proof-of-concept [especially one that would
>require me to learn GTK programming - something I've not yet touched]).
>
>I still think that if a proper abstraction layer is implemented, then
>parameters can either be "guessed" or silently discarded, thus enabling the
>widgets to be rendered in anything - even XWindows (or Win32 using Vis
>Basic, or a dialog resource file). Note that in these cases, only very
>generic code can be generated, but it's still possible.
I would agree that the current widget set can be used to create a
displayable component for Xwindows instead of a string of HTML.
But it's all the event stuff and callbacks and the like that seem like
extending the widget abstraction to GUIs is dangerous when the widgets I
want only require the capability of being delivered based on a simple
request/response protocol of HTTP so that a request comes in, the
script/controller processes it and then static text or components are
delivered down the wire that is HTML or WML or whatever but it's still
request/response.
Anyway, I don't mean to force anything down specifically. But I do know
that making things complex also leads to a lack of adaptation and a lack of
time for developing components. What I would like to see happen is that a
simple API is discussed and agreed and the basic objects are created.
Then given the assumption that those objects are simple, many more people
can implement them. If I have to be concerned about a lot of stuff
everytime I make a widget like multilingual support hooks and event hooks
then I will never write a widget because I don't have time.
This is why I want widgets to be tiny and atomic. Let's make it simple. If
you want multilingual can there be some way of making the multilingual
features a wrapper around existing atomic widgets? Same for events and
other such expert features.
Re: Real Widgets and Template Languages
At 04:28 PM 5/31/01 -0700, brian moseley wrote: >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 >;) Yes, but this is a more direct containment than a form which is likely to have many elements in it other than widgets. In this case, a widget directly contains other widgets. I think this is potentially OK and makes it easy to create a template-based tag. But when you have to keep track of a form tag that has widgets inside but may have arbitrary HTML as well, it's a more difficult/complex problem. As I have mentioned in a previous mail here, I think a composite widget is probably reasonable (for the locale and html vs wml output) but likewise, a composite widget could also be used to configure other widgets displaying simultaneously (and not as a switch based on language) to determine order of menu items and labels and whatnot. While I think these examples are good and they show advanced thought in all sorts of things widgets can be used for. The reality is many of these things are exceptions that are usually more an issue for windows systems than the abstraction that I would like to deal with a majority of the time -- just making my dealing with FORMs easier than it is now, within a short period of time was and is my primary goal. If you can accomplish the things you want without changing the basic behavior and without forcing me to fill-in a huge API whenever I write a widget class, then that is fine. But I think we need to focus on the *core* API and getting the *core* objects out so that they can be used. I believe atomic widgets, if we can at least agree on that can be fine for me and all of you who want fancy stuff can write controllers and composite widgets that do you fancy stuff exactly the way you want. I just don't want the widgets themselves to be large and difficult to implement.
Re: Real Widgets and Template Languages
At 04:21 PM 5/31/01 -0700, brian moseley wrote: >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? Our own. But I understand Struts apache project has the same basic deal (as also confirmed by Matt Sergeant's post). And from looking at Struts I think their model is even simpler than the model we have in our Java toolkit. This is why I am quite frightened of all these additions to a widget API in Perl when I know it's been accomplished so simply as a framework in Java. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Real Widgets and Template Languages
At 03:36 PM 5/31/01 -0400, Robert Landrum wrote:
>At 10:51 PM +0800 5/31/01, Gunther Birznieks wrote:
>>At 11:02 AM 5/29/01 -0400, Robert Landrum wrote:
>>>At 9:53 PM +0800 5/29/01, Gunther Birznieks wrote:
>>>>At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
>
>>>[...]
>>>Yes, but that's only because it defines 4 widgets... I'd probably
>>>expect somewhere between 50-100 widgets on average, and more the 500 in
>>>extreme cases.
>>
>>Really? I think you are an extreme case then. Do you really have more
>>than 50 form elements on a page usually? I think the container of the
>>widgets is roughly equivalent to a page that has to be rendered. It isn't
>>necessarily every widget in the entire app.
>
>Not on a single page, but throughout an entire site
>
>And we're not just talking about widgets that draw input boxes... Widgets
>are any page elements, such as images, buttons, links, etc...
>Right? Perhaps the way I've implemented widgets is different from the way
>you implement widgets.
>
>I define a widget as any configurable, reusable, code segment that
>produces output intended to be view by the end user.
>
>For instance, we have something called a
>CapWiz::Widget::CongressToday. And to call it, you pass it data from the
>database, and any configuration options, and out comes HTML.
>
> my $w = CapWiz::Widget::CongressToday->new({
> 'data' => \@records_from_database,
> 'color' => '#CC',
> 'width' => 385
> });
> $r->print($w->draw());
>
>And we have several hundred (200+) of these widgets to draw everything
>from Member Vote Tallies to Navigation Elements.
>
>Keep in mind that this is just how we have implemented widgets, and our
>only requirement was that it output XHTML... Not WM/WAPL, JavaScript, or
>GNOME/Gtk code.`
I think the way you are describing widgets is somewhat different from how I
describe widgets. While widgets can be overloaded to be a draw-only
component, the idea behind widgets is really as an application medium *not*
a content management medium.
What you are describing is closer to a model like Zope. Whilst I agree that
content mgmt is important, my gut feeling is that there are subtle
differences that make abstraction of simply any component like this quite
hard. And that's exactly what I would call them, components.
A widget has a specific behavior and is meant to interact with an
application, have form data sent to it, have the data posted and sent back
to data validator in the CGI script. etc I am not a content management
guru, but I am frightened about the possibility that something as difficult
as CMS will break into a version 1 widget library unless it's really clear
that it won't bloat the API.
I do not have experience with CMS, but I imagine it must be complex or Zope
for Perl would already exist today. Although perhaps the same could be said
for widgets. :)
>>>A perl hashref config file requires knowledge of perl data structures,
>>>which most designers won't grasp. Since I'm not the designer for my
>>>site, nor am I the guy
>>
>>This is true.
>>
>>>developing the underlying data structure, I wouldn't feel comfortable
>>>using perl as the config file. XML makes for a nice, easily understood
>>>medium for communicating configuration directives.
>>
>>Yes, but nice as an option. The worst part about an XML Config file is
>>everyone will have differences of opinion about what to XMLify and how
>>complex to make the defaults. So I think it's best as noted before, to
>>leave as a subclass.
>
>Agreed.
And I guess through this mechanism you could use widgets as your components
because you'll probably a very complex config because of how many widgets
you are dealing with in the scope of CMS.
Later,
Gunther
PS I am posting these last few msgs to mod_perl because I only just
subscribed to the sourceforge list (which I recommend everyone doing). But
I am waiting a day to let everyone else get caught up as well on signing up
so that the first posts will go to everyone.
Re: Real Widgets and Template Languages
At 09:14 PM 5/31/01 +0200, Issac Goldstand wrote:
> > At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
> > >At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> > > >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
> > >...
>[...]
> > >The caller in this case has already cooked up a bunch of HTML and is
> > >counting on the widget to produce HTML which can be inserted.
> > >The widget does *not* have the freedom to render any other way.
> > >This is why I have (sort of stubbornly) stuck with the $widget->html()
> > >method despite the unanimous suggestions for a $widget->display()
> > >method.
> >
> > and then also ->wml() and ->X() and whatever else? This does not seem
>right.
> >
> > >I do believe there is a place for a display() method, but it is at
> > >the controller level. The is the level at which the caller may not
> > >know what technologies are being used by the widgets.
> >
> > Yes its not at the controller level. It is at the widget level. So you
>have
> > Widget::WML::TextField and Widget::HTML::TextField...
> >
> > And the firsto ne would go into a controller that is set up to contain WML
> > widgets in general and the second would go into a controller that is set
>up
> > to contain HTML widgets in general.
>
>This is also doable, but only if it's transparent to the user. In other
>words, the developer _using_ the widget would have to mkae a
>Widget::TextField, and only when it was _rendering_ the Widget, would the
>libraries internally read the information in Widget::HTML::TextField or
>Widget::WML::TextField - otherwise, it's just not worth making "generic"
>widgets.
In my opinion, this is very difficult in practice. The widgets should be
atomic and do as little as possible. On occasion, application-specific
widgets would be created to do interesting things like Dates to pull
together several form fields.
However, I think you can accomplish this dispatching to WML and HTML
printing by using a composite widget or a widget container or the widget
controller. It doesn't really matter which abstraction is used. You can use
all 3 by merely subclassing widget and using a composite design pattern
without bloating the original API.
I want to keep the original API simple.
>[...]
> >
> > Here's my constructive criticism. The design constraint on the widgets
>here
> > is that you should assume a request/response model through HTTP for this
> > library and basically assume compatibility with template libraries that
>use
> > HTTP as a medium. X windows and curses and all that kind of stuff is not
> > appropriate and will confuse the API from an HTML perspective.
>
>I disagree. I think that by having dynamic parameters for the widgets, in
>conjunction with my "driver" idea, this can be made a lot more flexible
>without these problems. It would take planning out, but if we make the
>"snap-in" environment work correctly, then simple users who want easy HTML
>can do that easily, while a developer writing a template that will display
>on X-Windows as well as it will on a cellphone screen gets the HUGE benefit
>of constant widgets in a single template. Now for advanced stuff, we may
>very well need complex parameters - possibly even on a per-widget basis -
>but this should be on an "extended parameters" basis.
I disagree because the *behavior* of widgets in a free form, event driven
environment is much more complex than a request/response protocol. Behavior
differences means added methods and added complexity to the protocol as
well as what a developer has to do to implement a widget.
It's quite possible that it was wrong to call this a widget project and it
should really be HTTP::Widgets because I don't think these are widgets you
want to use in Perl/TK.
>Since I'm actually starting to trip over my own words here, let me try to
>illustrate with an example (note that I'm pulling methods and objects out of
>thin air - the idea is to illustrait the idea I brought up, not necessarily
>offer a draft of it):
>
>Complex Widget:
>
>TabStop="True" TabIndex="3" name="text1" value="some sample text"
>tooltip="Enter some text here"/>
>
>Now, let's say that the developer prints this with the HTML "Driver" - this
>could do something like:
>onMouseOut="Window.status=''"/>
>
>And in some other GTK-based environment, it could do something like:
>
>Label text1;
>with (text1)
>{
> .Length=50;
> .Width=25*XCharSize; // The *XCharSize would have to be defined by the
&
Re: Real Widgets and Template Languages
At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
>At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
>...
> >>$widget = $wc->widget("first_name");
> >>print "First Name: ", $widget->html(), "\n";
> >
> >A widget type has already been defined. So I don't see that the method to
> >output it's display should be called html() which is, well, HTML specific.
> >I prefer
> >
> >print "First Name: ", $widget->display(), "\n";
> >
> >Since widgets are components that know how to display themselves whether
> >its WML or HTML or whatever.
>
>This is a philosophical design decision that I have been struggling with.
>The widget does indeed know that it should generate HTML, so it could have
>a method, $widget->display(), $widget->draw(), etc.
>
>However, this implies that the widget has the freedom to decide how it
>should render itself and that the caller does not need to know.
>This is not correct.
I think it is correct. The widgets are specific to the technology like HTML
or WML or whatever. It's up to your config in the Controller to determine
which widgets you are putting into the controller.
If you want to display both WML and HTML, you would create a WML controller
and an HTML controller. Note that the controller itself doesn't know the
difference, but you just are using it as a collection mechanism to group
together like-sets of widgets.
>The caller in this case has already cooked up a bunch of HTML and is
>counting on the widget to produce HTML which can be inserted.
>The widget does *not* have the freedom to render any other way.
>This is why I have (sort of stubbornly) stuck with the $widget->html()
>method despite the unanimous suggestions for a $widget->display()
>method.
and then also ->wml() and ->X() and whatever else? This does not seem right.
>I do believe there is a place for a display() method, but it is at
>the controller level. The is the level at which the caller may not
>know what technologies are being used by the widgets.
Yes its not at the controller level. It is at the widget level. So you have
Widget::WML::TextField and Widget::HTML::TextField...
And the firsto ne would go into a controller that is set up to contain WML
widgets in general and the second would go into a controller that is set up
to contain HTML widgets in general.
>This whole discussion brings out two other important design decisions.
>
> 1. What are the UI technologies we really wish to support?
> (i.e. is this *really* a Widget or an HTML::Widget library?)
> 2. Which classes represent Logical Widgets and which Physical Widgets?
>
>1. TECHNOLOGIES
>
>I propose that the following technologies will have supporting
>Controller/State/Widget combinations to make this not just another web
>widget library.
>
> * CGI/HTML - a web application
> * mod_perl/HTML - similar, a web application using mod_perl
> * WAP/WML - driven from a WAP device
> * X11 (Gtk-Perl)- an X windows application
> * Curses (terminal) - a screen-oriented terminal application
> * Term - a line-oriented (scrolling) terminal application
> * Cmd - similar to Term, but the state must be saved
>between each cmd
>
>(I know I'm stretching the paradigm a little bit here, probably beyond what
>is reasonable.
>If you don't think one or more of these is a good idea, please keep it to
>yourself.
>I have a vision for it, and even if it's not very useful, it will shape the
>"abstractness"
>of the design elements. On the other hand, I would welcome suggestions for
>additional
>UI technologies that I might consider supporting.)
>
>One of the primary design rules is to *not* fall into the "least common
>denominator"
>trap. Many cross-platform application frameworks have done this and failed.
>Rather, the design goal is to *enable* the widget to fully utilize the
>capabilities
>of the technical environment it is in.
I very much disagree.
Least common denominator is not a trap. It's a design decision. This is why
design patterns have consequences. Different design choices mean different
things. I think you ask for failure and bloatedness when you try to ask too
much of an API.
The attempt to make this widget library even encompass X-Windows and normal
GUIs is frustrating to me. As I have mentioned in a previous mail, I
already use this technology on Java and JSPs. This is taking a small and
simple concept and blowing it way out of proportion.
Ok, that's the end of that rant and rave.
Here's my constructive criticism. The de
Re: Real Widgets and Template Languages
At 05:14 PM 5/29/01 -0500, James G Smith wrote:
>[EMAIL PROTECTED] wrote:
> >Where is this language value coming from? The widget's container. You only
>care about English? Then set it to "EN-US" and forget it.
>[snip]
> >Implementation strategies can be as simple as:
> >
> >
> >sub label {
> >
> > my $self=shift;
> > my $lang=shift || $self->container->language;
> >
> > if (exists $self->{'label'}{$lang}) {
> > return $self->{'label'}{$lang};
> > }
> > return $self->{'label'}{$self->container->language('default');
> >
> >}
>
>Something I've seen elsewhere is to have a master table of strings that the
>widgets can then reference.
>
>Different ways of doing this:
>index strings by number (MicroSoft resources in executables);
>index strings by the string in a particular language (TWIG with
> English as
>the indexing language).
The latter is what Java does by default with resource files associated with
servlets.
>This allows for sharing of strings across widgets and memory savings,
>always a
>good thing in mod_perl. It also doesn't slow the system down much if any
>compared to storing the strings in each widget with duplication.
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...
Re: Real Widgets and Template Languages
At 10:23 AM 5/29/01 -0500, James G Smith wrote: >Gunther Birznieks <[EMAIL PROTECTED]> wrote: > >At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote: > >>The rendering of this widget as HTML requires at least the following > >> > >>* config information (Widget::Config) >[snip] > >> >Also will we require XML to configure? Or is this also an optional > feature > >> >that you more or less want for yourself but others can choose to not use? > >> > >>Configuration data is read in via the Widget::Config class, and this class >can > >>be replaced with a class which reads config data from any other source, as > >>long as > >>it conforms to the same calling interface. > >> > >>I was under the impression that XML was your desired means of writing a > >>config file. > >>Do you have a preference to use something different? > > > >I like XML for Config files, we use that in our Java stuff all the time. > >But Perl is one of the nicest and flexible config file languages out there. > >IE My config file is Perl. > > > >Anyway, I think it is weird to think of configuring just widgets. Usually > >you configure an application and widgets are a part of that. But everyone > >here will have a different way of preferring to write their application > >config whether it's XML or Perl and what features of these that are used > >(eg just a set of scalars or references to hashes or ... ?) or in the case > >of XML using attributes versus subtags... > >IMHO, having a configuration API is much better than requiring a particular >way to do configuration. If the backend configuration is done via Perl code, >then any configuration file format can be supported with an appropriate >module >handling it. YES! >These widget configurations will need to be flexible enough that I can >construct a page with them without any knowledge of how they will look -- the >configurations should be tie-able to an overall theme for the site. I've >always been a champion of themes for websites. I should be able to select a >configuration at run-time without a lot of trouble. I agree. I think this is basically a capability that exists in the rough draft of the widgets though.
Re: Real Widgets and Template Languages
At 10:27 AM 5/29/01 -0400, Stephen Adkins wrote: >At 09:49 PM 5/29/2001 +0800, Gunther Birznieks wrote: > >At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote: > >>Hi, > >> > >>Development of a straw-man set of Perl Widget Library core classes is > >>going well. A Sourceforge project (perl-widget) is in the process of being > >>set up too. (I will announce when it is set up.) >... > >>The state information can be accessed from *any* source by implementing an > >>appropriate > >>WidgetState class (and using some additional, > >>not-yet-implemented arguments > >>to Widget->controller()). > > > >I think it would be better as a Widget::State:: rather than the > >other way around. From the way you describe it, this is really an interface > >to getting state information that should be retrieved from a DataSource > >specific state driver. > >I have come to the same conclusion. >I am changing the design to have three core base classes (other than the >widgets): > >Widget::Controller >Widget::Config >Widget::State > >A CGI program might run with the following derived classes: >(These are the initial defaults I am working on.) > >Widget::Controller::CGI >Widget::Config::XML >Widget::State::CGI > >All of these "drivers" may be overridden, as long as the driver you replace it >with conforms to the interface definition described by the core base classes. >(Kind of like a Java interface. You would be encouraged to derive from the >core base classes, but that is not necessary.) >... I think this is good. > >> > > >> >I don't understand the Widget::Controller. Can you say more about this? > >> > >>The Widget::Controller (or perhaps, Widget::CGI::Controller) is the > >>container class > >>that you spoke about in your original post. I call it a Controller rather > >>than > >>a Container because I envision it being able to dispatch events generated > >>by the > >>widgets. > > > >Ah. I just want something to contain the widgets essentially. So perhaps > >from my perspective events aren't necessary and I would potentially just > >place the widgets into an array representing my HTML screen. > > > >I have found that event handling comes in surprisingly handy even for >simple tasks. >Essentially, it allows widgets to define callbacks. >For instance, the DateDropDowns widget defines an event "change" >(modelled after the Javascript "onChange" event) that, when triggered, >concatenates >the , MM, and DD back into -MM-DD. >The following is working code. >Notice that the "$wc->dispatch_events($query);" statement takes care of >whatever widget housecleaning there may be (in this case, recomposing the date >as a single variable from the three drop-downs). Oh that's what you mean by events. Hmmm. I don't think this is really an event as much as a massaging of data back and forth based on the widget data source interface. I don't think there are really events like JavaScript, so it seems to me like it would be a bit confusing to apply a model that is based around a real UI like JavaScript to something that is purely a simple request/response protocol. >I had the hunch that everyone's configuration needs would be different. >Hence the Widget::Config (interface) and Widget::Config::XML (driver) >design. (Thanks for the input.) I think this is reasonable. Although if you see my post to Jay, I would prefer if the core config is then through Perl data structures. And then all the drivers would map the XML and what have you to the Perl data structures that are native for speed.
Re: Real Widgets and Template Languages
At 11:02 AM 5/29/01 -0400, Robert Landrum wrote: >At 9:53 PM +0800 5/29/01, Gunther Birznieks wrote: >>At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote: >>> > >>>>I don't understand the Widget::Controller. Can you say more about this? >>>> >>>>Also will we require XML to configure? Or is this also an optional feature >>>>that you more or less want for yourself but others can choose to not use? >>> >>>Hi, >>> >>>Below is running code for the Perl Widget Library. >>>So far, there are only two widgets. >>> >>>* a generic Widget::HTML::Element >>>* a drop-down menu Widget::HTML::Select >>> >>>Are there early comments on the interface from Perl? >>>Is this shaping up into what was desired? >>> >>>Stephen >>> >>>shark:/usr/ov/acoc/dev/src/Widget/examples> more Widget.xml Widget.2 >>>:: >>>Widget.xml >>>:: >>> >>>>>maxlength='99'/> >>>>>tag='input' type='text' size='14' maxlength='99'/> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>This config seems simple enough that it doesn't seem that necessary to >>use XML. > >Yes, but that's only because it defines 4 widgets... I'd probably expect >somewhere between 50-100 widgets on average, and more the 500 in extreme cases. Really? I think you are an extreme case then. Do you really have more than 50 form elements on a page usually? I think the container of the widgets is roughly equivalent to a page that has to be rendered. It isn't necessarily every widget in the entire app. >A perl hashref config file requires knowledge of perl data structures, >which most designers won't grasp. Since I'm not the designer for my site, >nor am I the guy This is true. >developing the underlying data structure, I wouldn't feel comfortable >using perl as the config file. XML makes for a nice, easily understood >medium for communicating configuration directives. Yes, but nice as an option. The worst part about an XML Config file is everyone will have differences of opinion about what to XMLify and how complex to make the defaults. So I think it's best as noted before, to leave as a subclass. >>print "First Name: ", $widget->display(), "\n"; >>Since widgets are components that know how to display themselves whether >>its WML or HTML or whatever. > >What about draw? display might be misinterpreted. If I draw something, >does that mean I've displayed it? Under the Xwindow system, widgets are >drawn and then shown, IIRC... > >print "First Name: ", $widget->draw(),"\n"; I think this is a very good interface.
Re: Real Widgets and Template Languages
At 10:08 AM 5/29/01 -0400, Jay Lawrence wrote:
>My $0.02 on XML config files. Although they may be attractive to some,
>personally, I don't like them.
I personally do like them, but I find XML to be heavy weight for parsing in
mod_cgi. And many of my users are on normal cheap ISPs that would not
compile XML::Parser.
I use XML config files in Java because the considerations are different and
you can't code a config file for Java in Java without suffering a compile
step for the end-user. I prefer config files written basically in Perl.
>I see XML is merely the expression of the configurable parameters of the
>object. IE it is just a means to the end. Personally, I would like to define
>my widget properties through a GUI and then will probably use Storable to
>dehydrate and rehydrate my widget objects. I would never want to code up XML
>data and I don't think I'm alone. :)
Yes, but I think serialization is a different API than construction. I
think the default construction/config API should be raw Perl code because
it would be FAST. Then optional to allow Config objects to create that raw
Perl code based on XML or properties files or whatever someone wants.
>Definately when it comes to interchanging your widget data with another
>system something like XML really starts to make sense. I don't think it
>makes sense necessarily for your internal day-to-day operations.
>
>What I would advocate is that there are a variety of sources for widget
>configuration data from something as simple and elegant as Perl code to XML
>of some layout to Storable data stored in a blob field of a DBI source.
>
>e.g.
> $widget->serialize( [ "Storable" ] )
> returns scalar ref to Storable data
> $widget->serialize("XML")
> returns scalar ref to XML string
>
> $widget->define( \$StorableData [, "Storable" ] )
> $widget->define( \$XMLData, "XML")
>
>Then you can easily write a Widget Controller that can be configured as to
>what method to use and where to store it to/from.
>
>Ideally these methods would always be inherited from the base widget class
>which will dictate the runtime implementation of widget data.
This seems reasonable.
Re: Real Widgets and Template Languages
At 10:04 AM 5/29/01 -0700, [EMAIL PROTECTED] wrote:
>On Tue, 29 May 2001, Stephen Adkins wrote:
>
> > Right. I have many more requirements I eventually want to support
> > (such as internationalization). The trick is making the design such
> > that it works in the simple case for simple things, while supporting
> > advanced features for those who wish to use them. I think it is coming
> > together pretty well.
>
>I hope you didn't mean to say eventually! ;-) Me - I need I18L'n right off
>the top. If my widgets aren't multilingual then I'll have to go elsewhere.
>75% of my apps are bi and trilingual.
Sounds kinky.
Anyway, I think there are two things that have to be gotten straight.
1) I18L support should exist immediately such as being able to render a
Chinese label.
2) Multilingual support is VERY different from I18L and is MUCH more
complex. I vote no on supporting this.
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.
I should rather configure my widgets in French and other widgets in English
etc... And then I tell a multilingual container subclass about all my sets
of widgets and then using a setLocale(), then the getWidget() method will
return the appropriate configured language widget.
You also would need a Widget Config that is multilingual and can configure
the multi languages very easily.
But please do not touch the core widget api itself. Please please keep it
lightweight.
>I think we should bite the bullet and start talkin Unicode and ISO-639
>language codes right at the beginning.
>
>If a widget has a textual element to be used in rendering (ie/ label) it
>should have as many language forms as the developer requires. If a
>language form is missing it should kick down to a default language (EN-CA
>for example - otherwise words like colour and flavour will be mispelled ;-) ).
>
>Where is this language value coming from? The widget's container. You only
>care about English? Then set it to "EN-US" and forget it.
>
> $widget->container->language="EN-CA"
> print $widget->label
>"What is your favorite flavour of ice cream?"
>
> $widget->container->language="EN-US"
> print $widget->label
>"What is your favorite flavor of ice cream?"
>
> $widget->container->language="FR-CA"
> print $widget->label
>""
>
>I'm sure you see the pattern.
>
>Not every property should be considered polylingual but ones that contain
>textual or language-specific visual elements should be.
>
>Implementation strategies can be as simple as:
>
>
>sub label {
>
> my $self=shift;
> my $lang=shift || $self->container->language;
>
> if (exists $self->{'label'}{$lang}) {
> return $self->{'label'}{$lang};
> }
> return $self->{'label'}{$self->container->language('default');
>
>}
>
>My personal strategy to date is to create meta data describing the class
>in general. Accessor functions for properties are created dynamically via
>AUTOLOAD mechanism. Based on metadata for class in question the AUTOLOADer
>will setup the accessor using one of a few different behaviors.
>
>In closing - although it seems like a drag in the beginning - it really
>makes sense to develop applications and components to support multiple
>languages. It is a zillion times more difficult to cobble in the
>fucntionality after the fact.
Just don't make the core library have to support multilingual. This is just
another bloated thing I don't want. It's fine for the hooks to exist, but
not the logic.
I don't mind if you make a subclass to support multiple sets of widgets as
described above, but please do not add so much that this becomes a huge
project.
Re: Real Widgets and Template Languages
At 05:52 PM 5/28/01 -0400, you wrote: > > Let's focus a bit. > Specifically on requirements more than implementation - *GOOD* I think you misread my intention. I think the requirements are simple and fairly clear except for some interesting enhancements people (includign yourself) propose on the list. I'd like to get a set of objects out more quickly that only do a few things well and in a small lightweight interface. >Could I paraphrase or reinterpret what you have said to be base classes >for handling widget properties and data sources? > >In the web world I see data coming from: > static widget properties - design/configuration values > user supplied values - Session and Request values > data sources - RDBMS, LDAP, yadda > >In addition I do see a variety of flavours for this data: scalar, array, >hash. Me, I want even more exotic flavours such as language sensitive (The >lable property check's user's language choice and will give them back the >lable in the right language). In order for a widget set to be useful we have >to agree on how to pass around a certain set of potentially complex data >types. > >READ: robust base object class with potentially fancy strategy for >rationalizing a number of data sources and data structures. This is very vague to me. It just doesn't sound very concrete enough. I think an interface to be able to do reference to a hash where values are either ref to an array or scalar is good enough initially. >Additionally - when it comes to widget-specific actions - such as rendering, >then you're seeing this as a subclass (or group of methods) that has been >defined by the widget creator. > ie/ widget->render - generic method that checks container and calls >appropriate render subclass for this widget > since container is HTML return widget->render_HTML or whatever. I think breaking out render subwidgets is too complex for my tastes. >READ: object hierarchy. Objects check their parents for hints on how to do >things - like pick the form to render themselves, etc. > > > 1. Data Validation logic. No, this does not belong there. This is a > > separate library. I already have a rich Data handling library in my >toolkit > > that I intend to plug widgets into. All I need is to be able to get widget > > data from the data handling/validation library. > >If I place a widget into my user interface and allow a user to specify a >value how I am I to implement validation? > >ie/ Widget has property "choice" which can be "1","2", or "3". If the user >supplies any other value I want choice to be NULL and raise an error. > > A - does controlling application logic enforce choice validation > B - does widget have property information to say that choice property >must pass some validation process? > >I like B because it further compartmentalizes the behaviors of the widget >within its own specification. The source of the valication routines can be >external to the widget and classes but the validation rules would be >specified within here. This is exactly why config should not be part of the widget library except as a side optional item. You can make your config also optionally configure data handling rules, but mine might not. Then its up to your app toolkit (if it wants to) to set up the data handler methods to be called when the form is submitted to the CGI based on that config. > > 2. External display stuff. No, I just want the widget to know how to draw > > itself and only itself. It's up to a template language plugin like TT or > > some other template language to provide the wrappings. Or it can be a > > toolkit like your drawing forms library -- but the widget itself shouldn't > > have to know about external decoration around it. Just how to draw itself. > >If one is to create an HTML form on a web page then all of the form elements >should actually be contained within in a FORM container. The FORM container >can then facillitate the correct development of HTML etc. > >If the widgets are used within another context then the FORM container might >be necessary or it might not. But it is usually easier to ignore than try to >backpeddle and whack stuff in after its kinda too late. It's pretty rare for this to be an issue. If it is, I would rather see a form become a widget that is linked to another widget if you really require functionality like this. > > It's possible, but I am not quite sure because the primary complexity >seems > > to be the data handling (which I have already in a separate abstraction) > > and the UI generation which I have already in Template Toolkit. So all I > > really want is an object abstract called a Widget along with a > > WidgetCollection to allow grouping widgets together that belong on a given > > HTML page. > >The way I am seeing a solution come together is somewhat different. First of >all I am now tending to really really really want to work with persistant >object collections. As my application needs new
LDAP utilities (was: the widgets thread)
At 10:49 AM 5/28/01 -0500, James G Smith wrote: >Gunther Birznieks <[EMAIL PROTECTED]> wrote: > >At 02:31 AM 5/25/01 -0400, Chip Turner wrote: > >>Gunther Birznieks <[EMAIL PROTECTED]> writes: > >> > >> > However, I think it is reasonable to make the interface to support a > >> > data source for the widgets flexible and object based to make it easy > >> > for someone to write a DBI source, a DBM source, an LDAP source, an > >> > Apache::Session source or whatever anyone wants really. I happen to > >> > think DBI and Session sources are cool. > >> > >>I agree; unfortunately writing classes to interface to all of these > >>would be difficult, and it would be difficult to be futureproof. When > >>you hit LDAP and DBI you must then worry about databases, tables, > >>servers, usernames, passwords, etc. It can become cumbersome to do > >>the simple things. > > > >I disagree. I've written interfaces like this before to LDAP and DBI. The > >constructor (or config method) on a data source is stuff like usernames/ > >passwords, and in the case of LDAP, schema mappings. > >Hmm... Something I'd like to see is a set of classes in Perl for managing >LDAP. These classes would need to be generic (configurable) enough to work >with any LDAP schema. They would need to provide an audit trail, transaction >log, etc., that could be used to replay changes made to LDAP. They would >need >to be able to enforce data consistancy across branches and data >integrity. If >noone gets to it before I do, I'll port my PHP code to Perl :) I guess it depends on what you store in LDAP. I find that LDAP is useful for simple data structures but it can be much nicer to also have the data in a relational database for most applications to access things in one query. I think I would like to see a public domain LDAP management console. This is really what you are talking about right? One of my coworkers wrote one in Perl back at Barclays Capital several years ago but he never bothered to open source it. I suspect there are a ton of places like that which custom design something like this and then never open source it due to laziness. >Oh, and locking mechanisms used must be transferable between machines -- I >lock resource A on machine X and then hand off the lock to machine Y -- this >code must be useful in a distributed environment (web farm) and robust enough >for use in a PKI. I guess I don't understand. The locking bit sounds slightly odd to me. Wouldn't it be easier to administrate a master LDAP server and have a push model of replication? I am not sure what you mean by robust being a prerequisite for PKI? Passwords are passwords -- just that certificates are larger and the SSL protocol has already decoded it for you. In fact, certificates can be easier depending on how you deal with it. If you just look up a Cert Revocation List then you can take the SSL decoded cert to be whom the user says she is without doing an LDAP lookup. Then LDAP is only used for user attributes and it has less to do with PKI. You only need to really store the certs in LDAP if you are talking about a certificate management system. And then that system should be protected anyway (the PKI management system) and probably won't need to be clustered as an app. Of course, perhaps you use it differently than I am thinking of LDAP and PKI.
