Re: cookie managerment
On 5 Sep 2003, at 04:48, James.Q.L wrote: in mod_perl how do i detect if users choose to reject the cookie being sent to them and/or having the cookie disable in browser ? (not javascript or other client-side scripting) so that i can print a error message remind user to enable cookie. Here's a scheme that works for me: Set the cookie. Redirect them to a page that expects the cookie. In your handler, if you're visiting a page that expects the cookie you take one of two actions: - If the Referer was the page that's supposed to set the cookie, send them to the page telling them to turn on cookies. - Otherwise send them back to the page that sets the cookie (usually a login page). It's a simple scheme, and relies on Referer which everyone will now tell me is bad, but it does work. Matt. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: $r->headers_out Location and Set-Cookie
On Saturday, Aug 9, 2003, at 15:26 Europe/London, Nick Tonkin wrote:
On Sat, 9 Aug 2003, gerard uolaquetalestem wrote:
I have the next problem, i am in page A that points to page B,
that is
a modperl2 handler.
This handler makes a job and decides to send a cookie to the browser,
and
after to redirect to the same page A who is ready to catch the cookie.
Yep. You need $r->err_headers_out->{'Location'} and you could change
to $r->err_headers_out->{'Set-Cookie'} too.
Even that doesn't work. You need to do a Refresh, because that's the
only way the browser will register the cookie - Set-Cookie + Location
is not compatible (generally - some browsers will accept the cookie).
Matt.
ANNOUNCE: AxKit 1.6.2
The AxKit Development Team are proud to announce the release of AxKit 1.6.2. This release is a minor bug fix and small features release. You can download AxKit 1.6.2 from http://xml.apache.org/dist/axkit/ or via a CPAN mirror once CPAN propogates. Changes in this release: - Made processors added via AxAddDynamicProcessor appear in their proper order based on the order in which they appear in the config files (rather than simply appended on to the current processing chain). - AxAdd*Processor outside of blocks now are global, instead of in the '#default' style name - XSP attribute values are now interpolated like in XSLT, to save you having tags all over your XSP code. - Added a test suite based on Apache::Test (yay!) - A number of XSP bug fixes - Support HTTP HEAD requests - Custom content providers now interact properly with the dependency tests - AxTraceIntermediate now creates the dir if it didn't exist - Other assorted minor bug fixes -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
Re: templating system opinions (axkit?)
On Mon, 28 Jul 2003, Andy Wardley wrote: > Jean-Michel Hiver wrote: > > Because Petal templates have to be well-formed XML, > > XML syntax is crufty at best. There's a lot in XML that is needless, but like perl still has a dump() function, we just say "don't use that then". At it's core, XML is a very elegant syntax for defining a rich dataset of nodes, and solves many of the problems that text markup systems still struggle with reinventing (such as different encodings - YAML for example forces everyone's document to be in one of the UTF encodings). > It requires you to be strict and tediously > correct with every character. Many believe this is a good thing with a templating language. Let the browser be flexible in what it can receive, but let us, as professionals, be strict in what we generate. > You have to shoe-horn the semantics of your > complex directives into the limited syntax of element-name-and-attributes. > The language becomes contrived and clumsy as a result of trying to satisfy > a purity of design. This I can agree with, having written my own templating system because I didn't like XSLT's idea of being written in XML :-) But I now use XSLT, because it has other benefits (portable, fast, etc). > and you find yourself tied down to only generating valid > XML (which few real world web pages are, even if they should be). My web pages come out as HTML 4.0 transitional, not XHTML, and they are generated with XSLT. They often omit closing tags where appropriate for HTML. I don't do any fancy post-processing. Sorry Andy, but the above is not true at all. > Vive la difference! As you can see in evidence (Apache::AxKit::Language::*), I agree. -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
Re: templating system opinions (axkit?)
On Mon, 21 Jul 2003, Patrick Galbraith wrote: > Anyone on this list use AxKit? I'm curious how it pans out. > > I like the idea of XSLT/XML, though I find myself trying to read between > the lines of hype vs. something that's actually very useful. I don't know, > so I don't have any opinions. I do know I'd like to use XSLT/XML so as to > have a project to use it for, hence learn it. I'm just about to roll out a site using AxKit that has to do about 3 million hits/day out of the box. The main reason I like AxKit is it prevents me from screwing up and creating XSS bugs, because everything has to be well formed. I almost never have to use html or URL encode/decode functions - I just write straight perl code. I barely notice that I'm using XML. It's also worth noting that XSLT is a portable skill, with lots of great offline tools. It's also worth saying: never listen to hype. Evaluate solutions based on your criteria. AxKit matches mine but it doesn't mean it will match yours. Matt.
Re: templating system opinions
On Monday, Jul 21, 2003, at 02:23 Europe/London, Dave Rolsky wrote: All of this said, what is the most commonly used system out there? The biggest players are Mason and Template Toolkit, judging from "big companies" that have used them, as well as job posting. HTML::Template, Embperl, and Apache::ASP all seem to have reasonably active user bases as well. And lets not forget XML templating solutions too, like XSLT, which probably out scores them all in job postings terms (although not all that work is perl related). Matt. (you can of course use XSLT in AxKit :-)
Re: Newbie question about mod_perl capabilities
On Monday, Jul 7, 2003, at 20:50 Europe/London, Ged Haywood wrote: On 7 Jul 2003, Walter H. van Holst wrote: I am new to mod_perl and am trying to figure out whether it suits my needs or not. Can I use it to intercept any http CONNECT requests Apache receives and answer those? The concept of a connection is at the transport level, way below HTTP. The HTTP protocol simply assumes a reliable transport (you don't even need an Internet:) and deals with exchanges of messages. See RFC1945. Sorry Ged, Walter is talking about CONNECT which is a proxy request. It goes in place of GET or POST in the request line: CONNECT mail.openrelay.com:25 HTTP/1.1 I *think* mod_perl will be able to intercept this, but I've never tried it. You might need to do it very early on in the request, and make sure it gets passed through to mod_proxy later on or things just won't work. Matt.
RE: MS SQL Server
On Wed, 18 Jun 2003, FARRINGTON, RYAN wrote: > omg... linux people using MS SQL servers? shame on you... =) I hold in one hand the option of taking a pager home with me. In the other hand is using MS SQL Server and giving support over to our 24/7 DBAs. Which would you choose? -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
Re: MS SQL Server
On Wed, 18 Jun 2003, Cosimo Streppone wrote: > > Any gotchas I should be aware of? I have a very high performance > > requirements application (millions of hits/day) and I need to know the > > architecture can cope with it (the alternative being PostgreSQL). > > Sorry if I mention obvious things, but I know of: > > 1) lack of placeholders support with DBD::Sybase + Freetds layer. >I used freetds 0.53, but 0.61 had the same problem for me. Ah, that explains why people are using unixODBC with the TDS driver instead. I assume that supports placeholders (?). Sounds like a bit of a showstopper to me! > 2) I wasn't able to use sql transactions in the same way >I normally do with postgresql/db2/informix/sybase/... >This could be due to my fault, SQL server version (?), >or other problems I couldn't track down. Any chance you can expand on that? I use transactions in the application heavily (it has been developed on PostgreSQL), and had feared this might be an area of contention. -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
MS SQL Server
Anyone got any experience of doing MS SQL Server from mod_perl on Linux (via the FreeTDS drivers)? Any gotchas I should be aware of? I have a very high performance requirements application (millions of hits/day) and I need to know the architecture can cope with it (the alternative being PostgreSQL). -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
Re: Cross Site Scripting
On Tue, 11 Mar 2003, Clinton Gormley wrote: > On Tue, 2003-03-11 at 06:03, Stas Bekman wrote: > > > Changes since 0.7 > > > > * prevent cross-site scripting, now HTML-escaping the request field > > > > In Stas' Apache::VMonitor announcement, he mentions changes to prevent > cross site scripting. > > This is a concern for me at the moment, because I'm building a site > which will allow people to submit copy (to be displayed to other users) > and I would like them to be able to use HTML and include links to other > sites (much like slashdot). > > Do any of you have any ideas about good techniques to prevent CSS (and I > don't mean those elements) in this scenario? I hate to blatantly advertise, but using AxKit mostly mitigates XSS (don't use the term CSS to mean cross site scripting - its confusing) bugs, with the exception of javascript in URLs and blank lines inserted into headers from a user submission. So you vastly limit the things you have to check for. -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
Re: How do I convert HTML to PDF
On Wednesday, Feb 26, 2003, at 17:41 Europe/London, Chris Pizzo wrote: Hi All, I want to take an Invoice that exists as an html doc and convert it to a PDF file to attach to an email. I have been looking at DocSet but this seems better suited for large documents. Any help? Check out HTMLDoc. http://www.easysw.com/htmldoc/
Re: child-parent memory access / mod_perl / shared mem / inter-proccess communication , etc..
On Monday, Feb 24, 2003, at 19:47 Europe/London, Jim Morrison
[Mailing-Lists] wrote:
What I thought was that if I kept the handle to the parsed XML open
somewhere else then I would be able to use it.. so a separate process
does the parsing and keeps hold of the handles of the currently
'shared'
bits of XML.. What comes out the other end is something along the
lines
of:
bless( do{\(my $o = 137110200)}, 'XML::LibXML::Document' )
But trying to toString() it for instance gives me a :
XML::LibXML::Document::_toString() -- self contains no data at
[snip]/LibXML.pm line 659.
To what does the "my $o = 137110200" refer? Is there no way I can get
the parsed object out of LibXML2 into another process?
It's a pointer to a region of memory. Since you have protected memory
in your operating system, only the process that malloced that region of
memory can access it, hence you can't access it from another process.
And no, you can't make XML::LibXML allocate in shared memory.
The only conceivable way you could do it is create the DOM before the
fork and rely on copy-on-write.
CAVEAT : I know it's probably looked at as a silly idea, but if I could
keep my parsed stylesheets/xml's shared somewhere I'd save my self
having to re-parse for every request wouldn't I? . .
Before you try this, *please* investigate parsing every time your
output needs to change (caching a-la AxKit). A very large site I know
tried this and discovered that XML::LibXML/LibXSLT parses stylesheets
*so* fast that it made zero difference to them to cache the stylesheets
in memory (shared or otherwise).
Try it. You may discover you don't need all this caching.
Matt.
RE: child-parent memory access / mod_perl / shared mem /inter-proccesscommunication , etc..
On Mon, 24 Feb 2003, Jim Morrison [Mailing-Lists] wrote: > Hmm.. Yes, it sounds pretty sketchy to me too! Immediately what I am > playing with is the idea of keeping parsed XML (XML::LibXML)in memory > between requests. Is this a completely barmy idea? Probably, because you'll confuse XML::LibXML's garbage collector. -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] libapreq-1.1 is out
On Thursday, Jan 30, 2003, at 22:36 Europe/London, Stas Bekman wrote: Matt, Apache::Test may not work when run under root, because Apache won't let you start the server as 'User root' so it tries to use 'nobody' or something else as the username the server runs under, which of course has no perms to access files created by root and hence the problem. I suppose the solution is to chown all the autogenerated files to that chosen user and then the issue will be resolved. Meanwhile please try to run the test suite as non-root. That's not enough. Ever tried to run an apache docroot from a directory that the parent directory is not rx by nobody? Doesn't work.
Re: [ANNOUNCE] libapreq-1.1 is out
On Thursday, Jan 30, 2003, at 22:51 Europe/London, Stas Bekman wrote: Matt Sergeant wrote: [...] It would help to know your platform details. We tried to eliminate all segfaults related to perl-5.8.0, but in the process we may have introduced new ones. perl 5.00503 on RH 6.2 and mod_perl 1.26 IIRC. The segfault was during the file upload tests. And the backtrace is ...? Sorry - this time I had a deadline to reach and the bug was intermittent and only during file upload so I could safely ignore it. I'll see what I can do though.
Re: [ANNOUNCE] libapreq-1.1 is out
On Thursday, Jan 30, 2003, at 14:46 Europe/London, Joe Schaefer wrote: Matt Sergeant <[EMAIL PROTECTED]> writes: On 28 Jan 2003, Joe Schaefer wrote: libapreq-1.1 is now available on CPAN, and also through the Apache website at http://www.apache.org/dist/httpd/libapreq/libapreq-1.1.tar.gz Failed badly to install for me. First of all it won't install via the CPAN shell as root because the test harness tries to deliver files from what becomes a root-owned directory, and it won't do that. The test suite was lifted directly from mod_perl. Are you able to able to test/install mod_perl using the same approach? I don't know - I'd never install mod_perl from CPAN ;-) But it's fairly easy to debug. su to root, extract the archive and try a make test. It's obvious why it fails. Easiest thing to do is skip those tests if you detect a root install, or if you can detect that the user running httpd can't access the directory and all directories above it. Secondly it seems to segfault my apache, so it leaves zombies lying around. Not sure if that's libapreq or something else though. It would help to know your platform details. We tried to eliminate all segfaults related to perl-5.8.0, but in the process we may have introduced new ones. perl 5.00503 on RH 6.2 and mod_perl 1.26 IIRC. The segfault was during the file upload tests. Matt.
Re: [ANNOUNCE] libapreq-1.1 is out
On 28 Jan 2003, Joe Schaefer wrote: > > libapreq-1.1 is now available on CPAN, > and also through the Apache website at > > http://www.apache.org/dist/httpd/libapreq/libapreq-1.1.tar.gz Failed badly to install for me. First of all it won't install via the CPAN shell as root because the test harness tries to deliver files from what becomes a root-owned directory, and it won't do that. Secondly it seems to segfault my apache, so it leaves zombies lying around. Not sure if that's libapreq or something else though. It's the first problem that needs fixing most. -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
Re: [mod_perl] Re: OSCON ideas
On Fri, 10 Jan 2003, Jonathan M. Hollin wrote: > Matt Sergeant wrote: > > I've done a lot on bayes for spam (I had an effective bayesian filter before > > Paul Graham wrote his article on the subject), but there's not much in it > > for a full talk. Maybe a lightning talk. Hmm... > > That would be great Matt. > > Funny how Paul Graham has become so synonymous with Bayesian > probabilities isn't it? Your work preceeds his, Google "Page Rank" > apparently uses Bayesians (pre-Graham) and, here in the UK, Autonomy > (http://www.autonomy.com/) have been doing ground-breaking work for a > few years now with Bayesians at the core of their technology. Despite > this, Paul Graham is the first person people think of when you start to > talk Bayesians, I wonder why? To be fair to Paul Graham, what he did was put it in a language that was accessible to geeks. Every single paper or book or whatever I've read on Bayesian probabilities talks in maths gobledegook (although I'm sure Ken Williams may disagree ;-). Paul Graham made it easy for the layman to grok and implement. A bayes lightning talk might be fun though. -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
Re: OSCON ideas - MVC talk
On Wed, 8 Jan 2003, Nathan Torkington wrote: > Ask Bjoern Hansen writes: > > On Wed, 8 Jan 2003, Perrin Harkins wrote: > > Like Perrin I would like feedback on the idea before putting in my > > proposal. > > I've also been asked if anyone has a wishlist of talks they'd like to > see at the conference. Ideally they'd be "talks I'd pay money to see" > but I could live with "talks I'd like to see even though they're hard > to justify to my boss". Feel free to brainstorm here as much as you > want :-) I might willing to do 20 mins on "How I ported my registry script to mod_perl 2.0 (a.k.a. mod_perl 2.0 war stories)". And no, I don't mean 45 mins. :-) -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED]
Re: NTLM module
Can you guys please snip the emails down to the relevant information? Having to scroll past lots of rubbish at the end of the email gets annoying (and I'm not even a digest subscriber). Thanks.
Re: *****SPAM***** Re: Modperl! Your spam awaits you
>> And of course, send whatever info we can to the RBL folks > > SpamAssasin does that - when a user gets spam which isn't flagged, > he's supposed to send it to a 'sightings' address. Matt, is that > still right? I'm still sending the stuff... > Yeah - but I don't read the sightings list - too much spam :-) Matt.
Re: [RFC] Apache::SessionManager
On Friday, August 2, 2002, at 05:40 PM, Enrico Sorcinelli wrote: > The only way that I know to have a session framework is to use mod_perl > application server like AxKit, HTML::Mason or Apache::ASP ... > Actually the AxKit one doesn't require AxKit - but it ships with an XSP taglib to access the values easily, that's all. Matt.
Re: [RFC] Apache::SessionManager
There's the AxKit one, which does something pretty similar - AxKit::XSP::Session I think it's called. On Fri, 2 Aug 2002, Enrico Sorcinelli wrote: > Hi all, > > I would like to propose a new Apache module before I send it off to > CPAN. The namespace I've chosen is Apache::SessionManager. > > This module is a an Apache/mod_perl module and use Apache::Session to > track user's sessions over HTTP request. > Simply Apache::SessionManager help me with session management. > > Apache::SessionManager creates an object session (in Header parsing phase, > but not obligatorily) and make it available to all other handlers > transparently by putting in pnotes. Others handlers can retrieve session > directly from pnotes or by calling the simple function > Apache::SessionManager::get_session($r) > > After some search on CPAN I haven't found a mod_perl module that does > the same thing (right?). > The module is work in progress, of course, even if already I use it. -- <:->Get a smart net
Re: [ANNOUNCE] Petal 0.1
On Wed, 17 Jul 2002, Jean-Michel Hiver wrote: > My only problem deals with template caching. Currently Petal does the > following: > > * Generate events to build a 'canonical' template file > * Convert that template file to Perl code > ** Cache the Perl code onto disk > * Compiles the Perl code as a subroutine > ** Caches the subroutine in memory > > Cache is kept fresh using the template file mtime() information. > > If I had a SAX event parser, then maybe caching could be a bit > troublesome? If you could skip the whole "perl code" part you could use XML::Filter::Cache (a SAX caching filter) as a cache rather than worrying about a built in one. Sorry for getting off topic for this list though. Just trying to pass around the SAX kool aid ;-) -- <:->Get a smart net
Re: ANNOUNCE: the new perl.apache.org is alive now!
On 12 Jul 2002, Randal L. Schwartz wrote: > Oh, and add Template Toolkit (www.tt2.org) to that list. You mean like this: > Matt> EmbPerl, TT, Mason, AxKit, ASP, etc... Perhaps live sites is a more ^^ ;-) -- <:->Get a smart net
Re: ANNOUNCE: the new perl.apache.org is alive now!
On Fri, 12 Jul 2002, David Kaufman wrote: > 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. Are there that many sites any more that are running pure mod_perl? I would expect most new sites to be running one of the framework modules - EmbPerl, TT, Mason, AxKit, ASP, etc... Perhaps live sites is a more framework specific thing (for example AxKit has its own list). -- <:->Get a smart net
Re: Working Directory
On Fri, 12 Jul 2002, Stas Bekman wrote: > Josh Bernstein wrote: > >After just upgrading to mod_perl2 with Apache2. My current @INC path > > includes a "." on the end, which should reference the current working > > directory, and therefore correctly locate include locate in the script's > > working directory. The problem is that the Working Directory is set to > > "/". My question is how can I set the working directory to be the > > location of where the script is running. (This would make mod_perl > > correctly locate file that I have included in the running script ie: > > require "./file.pl") Can this be done from within Apache? > > > >I've tried variations of PerlSetEnv but I can't seem to get it to > > work. I've even read the mod_perl2 user's guide. Thanks for your help.. > > chdir is not a thread-safe function, (there is only one CWD per > application) therefore the new ModPerl::Registry doesn't chdir to the > dir of the script. We have discussed various workarounds on the dev > list, but none of them has been applied yet. > http://mathforum.org/discussions/epi-search/modperl-dev.html > (search for 'chdir thread') Arthur told me he either had, or was going to fix this (on IRC). -- <:->Get a smart net
Re: Propogating Errors / E-Toys
On Wed, 10 Jul 2002, Perrin Harkins wrote:
> Matt Sergeant wrote:
> > On Wed, 10 Jul 2002, Fran Fabrizio wrote:
> >>Just to confirm, the end result of Matt's slide presentation was that
> >>Error.pm was good, and you should use it, but you should not use the
> >>try/catch syntax, or at the bare minimum only catch in your outermost
> >>handler. Is that correct? We were debating this just yesterday in our
> >>office.
> >
> > Actually my recommendation for this year's talk on exceptions is to just
> > use eval{}; if ($@) {}. It's a little more typing, but at the end of the
> > day closures created by subroutine prototypes are a really bad thing (tm).
>
> I believe he was asking if Error.pm is a good class to use for
> exceptions if you don't use the try/catch keywords. I think it is. It
> provides handy methods for storing attributes of the exception and
> getting stack traces, and it's easy to subclass. You could also use
> Dave Rolsky's Exception::Class, which is pretty similar.
Ah, in that case I'm recommending Dave's stuff. It's more flexible and
doesn't use that irritating -param stuff. Though I have to do a little
more research to be certain some things are possible (like turning on
stack traces globally).
--
<:->Get a smart net
Re: Propogating Errors / E-Toys
On Wed, 10 Jul 2002, Fran Fabrizio wrote:
>
> Just to confirm, the end result of Matt's slide presentation was that
> Error.pm was good, and you should use it, but you should not use the
> try/catch syntax, or at the bare minimum only catch in your outermost
> handler. Is that correct? We were debating this just yesterday in our
> office.
Actually my recommendation for this year's talk on exceptions is to just
use eval{}; if ($@) {}. It's a little more typing, but at the end of the
day closures created by subroutine prototypes are a really bad thing (tm).
--
<:->Get a smart net
Re: Propogating Errors / E-Toys
On Wed, 10 Jul 2002, Michael Schout wrote: > Perrin Harkins wrote: > > > > We've actually discussed this on the list. It has to do with closures. > > Matt gave a presentation about exception handling which covers it and > > shows a workaround. You can see it here: > > > > http://axkit.org/docs/presentations/tpc2001/ > > Sorry to chime in a little late on this. > > But the "Exceptions" slides from the page above are either misleading, > or I am misunderstainding just what exactly leaks in Error. I didn't say "leaks" in my slides. That's what you're misunderstanding. It merely creates a closure. This *can* lead to leaks, but doesn't always. I guess at some point I aught to pick up Error::Filter again. Damn that hard drive crash (which lost the source code I had for a source filter version of Error.pm, which didn't create closures). -- <:->Get a smart net
Re: XML::Xalan, Perl modules and bootstrapping... :-s
Jim Morrison [Mailinglists] wrote: > [Marked with "" ] (Try a real mail client ;-) > Interesting you should say that? I was under the impression that the C > version of Xalan was very quick? I am, in some cases running off 100 or > so transformations in one run, through quite complicated xslt's and > despite the fact that for every transformation my dodgy perl code builds > the XML from collections of flat xml files on disk, which then has to > get parsed.. (and in many cases more XML is brought in through > "document()"... I'm still getting a good 800 - 900 pages per minute.. > (on a little 500Mhz Celeron, 256Mb) > > Would LibXML perform better you think?? Is there somewhere I can find a > comparison?? Yes, LibXML and LibXSLT are faster, simply because the underlying libxml2 and libxslt processors are the fastest there are available - I think some people's tests now show them to be faster even than Microsoft's (which was always the benchmark to beat). I do still wonder why people get the impression you were given - it's widely known that the C version of Xalan is appallingly slow - slower even than it's Java counterpart. Matt.
Re: perl xml api's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 22 June 2002 12:57 am, [EMAIL PROTECTED] wrote: > Hi, My Mission(must accept it) is to retrieve xml-formatted mail, parse > thru char-sets in msg-body, if chars out of ascii range: generate err msg. > > While I wade thru the apis could any one suggest which modules would fit > this task? Will XML::Parser retrieve a doc from a url or must the doc be > retrived and handed to it? tips appreciated. md An XML parser will croak anyway if the chars are out of range. XML::LibXML has a built in ftp and http client for retrieving external URLs. Just pass a URI to the parse_file() method. - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9FCB2VBc71ct6OywRAl7mAKDPXzPGGOlCmIkTSYKArMfYuDnVaQCglGkM 5QlI1xWhyUJUl+BGW3ZYa90= =QNP1 -END PGP SIGNATURE-
Re: separating C from V in MVC
On Fri, 14 Jun 2002, Nigel Hamilton wrote: > > A) a ridiculously flexible interface that looks sort of like SQL, except > > where it is SQL, except where it's only sort of like SQL, etc. > > > > B) a ridiculous profusion of classes, methods, or both. > > > > SQL has its place, and Alzabo merely provides a thin layer on top of it. > > > > Trying to jam a thick layer of OO-goodness over relational data is asking > > for a mess. OO has its place, but if your application is primarily about > > the database, I don't think that a heavy OO layer on top of that will do > > HI Dave, > > Totally agree. > > My general motto is "tiers eq tears" ... I've never seen > a really comfortable OO/SQL bridge. > > The OO part almost always dumbs down or hobbles the database. > > Group bys, order bys, multi-table selects, locking, SQL query > plans and index optimisation all rightfully belong to the database but are > an anathema to a simple OO/SQL bridge. > > While disks need to seek and spin ... relational databases will > have their place. I sometimes think of a world with unlimited RAM. It's > here that OO dreams really come true --- vast pools of objects with > hash/array look up speed etc. I feel pretty much the same, and so gave a talk about this (and other things) at last year's perl conference. Slides are at http://axkit.org/docs/presentations/tpc2001/anydbd.axp/a.pdf -- <:->Get a smart net
Re: threads in 5.8 (was: mod_perl2.0 / TIPool)
On Thursday 13 June 2002 11:50 pm, John Siracusa wrote: > On 6/13/02 6:40 PM, Matt Sergeant wrote: > >> Does anyone know the logic behind making the threads modules all > >> lowercase? I'd expect it to be Threads::Shared, not threads::shared. > > > > Pragmas are lowercase. And use threads; is really a pragma. > > A pragma with class methods? A pragma that exports functions? Maybe I'm > confused about the distinction between a pragma and a module... It's a really fine line ;-) See also use fields.
Re: threads in 5.8 (was: mod_perl2.0 / TIPool)
On Thursday 13 June 2002 11:37 pm, John Siracusa wrote: > On 6/13/02 5:58 PM, Matt Sergeant wrote: > > Also note perl.com is now running an article on threads::shared. > > > > http://www.perl.com/pub/a/2002/06/11/threads.html > > > > It's mainly aimed at module authors, but it could be of interest anyway. > > Does anyone know the logic behind making the threads modules all lowercase? > I'd expect it to be Threads::Shared, not threads::shared. Pragmas are lowercase. And use threads; is really a pragma. Matt.
Re: mod_perl2.0 / TIPool
On Thursday 13 June 2002 10:46 pm, Doug MacEachern wrote: > On Thu, 13 Jun 2002, Stathy G. Touloumis wrote: > > Is there an idea of when the TIPool API will be available for mod_perl > > 2.0? > > probably never now that threads::shared has been implemented in perl-5.8, > which can be used to provide the same functionality (i think). > threads::shared came to be after writing about the Perl interface to > TIPool. Also note perl.com is now running an article on threads::shared. http://www.perl.com/pub/a/2002/06/11/threads.html It's mainly aimed at module authors, but it could be of interest anyway.
Re: XML vs Perl (Re: separating C from V in MVC)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 13 June 2002 6:20 am, Rob Nagler wrote:
> Matt Sergeant writes:
> > > This assumes you need XML in the first place.
> >
> > No, it does not. The rest of my post spoke about XML as a
> > data format and set of tools, not as a syntax. Please stop
> > thinking about XML as syntax!!
>
> If my entire system is written in Perl, why do I need XML as a data
> format?
Need is *not* what I said. But anyway, I already said: because of the tools.
Perl has nothing that even comes close to SAX as a clean way of doing the
"unix"-like thing of having small tools to do just one job when it comes to
data munging.
> Perl's data structures are richer and have much more support
> in Perl than XML has in any language. Perl has been around much
> longer and is full-fledged programming language. It has better
> tools. It's got a larger community.
We disagree on this.
> > You seem to speak as someone who has never tried by the sounds of
> > things. This is one of the things AxKit's XSP taglibs are designed
> > to provide for.
>
> I've never used XSP. I have used XSLT, tried to use XSD, and am
> currently mired in DocBook/XML. One of my sites generates XML for its
> data export format.
>
> Let's take an XSP example from axkit.org:
>
>
> Time::Object
>
>
>
>
> Why is the above better than below? (I cleaned up the perl :-)
>
> use Time::Object;
> sub mytime {
> my ($time) = @_;
> return Time::Object->new($time || time);
> }
>
> Or, why can't I just call Time::Object->new where I need it?
Erk. I knew the docs on AxKit.org were going to bite me in the ass one day.
This is a really *bad* example of XSP usage. It's not separating content from
presentation. Nowadays everything I do uses taglibs, which makes pages look
like:
http://axkit.org/NS/xsp/wiki/1";>
(yes, I'm writing an axkit wiki in case anyone's interested)
Anyway, that's off topic, because the point was you were trying to argue
(IIRC) why would you bother hand generating XML from your data just to get
access to XML tools. But XSP's two taglib modules (look at the docs on
search.cpan.org, rather than on axkit.org) do that conversion automatically
for you.
- --
<:->get a SMart net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9CErhVBc71ct6OywRAn67AJ9E9o+MAnvkbXutEycFk+y7LAEVQwCfeUuI
95rN/7rb51T9wLJgY3EamL0=
=c8HN
-END PGP SIGNATURE-
Re: separating C from V in MVC
On Wednesday 12 June 2002 4:09 am, Rob Nagler wrote: > Matt Sergeant writes: > > There's quite a few things that are a lot harder to do with XML in > > plain perl (especially in SAX) than they are in XSLT. > > This assumes you need XML in the first place. No, it does not. The rest of my post spoke about XML as a data format and set of tools, not as a syntax. Please stop thinking about XML as syntax!! > It's trivial to manipulate Perl data structures in Perl. It's > also easy to manipulate XML in Perl. However, it's impossible(?) to > manipulate Perl data structures in XSLT. You seem to speak as someone who has never tried by the sounds of things. This is one of the things AxKit's XSP taglibs are designed to provide for. Matt.
Re: separating C from V in MVC
On Tue, 11 Jun 2002, Ward Vuillemot wrote: > I know we are straying WOT, but I would love to get a better feel for > XML, XSLT and AxKit. There are a lot of different systems out there. . > .and part of me wants to just do it my way (in large part to learn), but > I also realize that I really want to get to the business of also being > productive. > > Per the below, I would imagine some would say XML in and of itself is > not worth considering as a contender for being the basis for our C of > MVC. AxKit bills itself as an XML application. Would ppl suggest just > using an XSLT parser. . .or is it worth looking at AxKit. > > If anyone is willing to share their experiences, knowledge, insight -- > off the ML is okay, too -- I would _really_ appreciate it! A while ago (couple of months I think) on the AxKit-Dahut IRC channel Eric Cholet was raving about how he had discovered how cool XML was. What really happened was that Eric discovered that XML isn't about the Syntax, which seems to be what everybody focuses on (especially perl people I find). The beauty of XML is in the tools. Things like SAX, which allow you to build a pipeline of specialised tools for munging data, are really why XML is so great. I really can't put it as well as Eric did at the time. I only hope by using his name out loud here I can prompt him to post something ;-) Basically I would just suggest that the set of tools for manipulating XML are better than most of the other tools you currently use for munging data about. Taken a step further, while perl is cool at munging text, most of us don't just deal with text - we deal with trees, records, etc. So by combining Perl and XML you get the best of both those worlds. The XML solutions I've seen tend to be the least "hacked" looking systems I've seen in my relatively few years of experience. I know that's not specifically about AxKit. What AxKit does offer is a mature stable system for bringing these tools together, plus it offers nice ways to deliver the same content in different formats. -- <:->Get a smart net
Re: separating C from V in MVC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 10 June 2002 11:23 pm, Vuillemot, Ward W wrote: >: Really interesting, xml >: appears to be >: the final destination for most of us, even if now i >: prefer objects. >: >: Ciao, Valerio > > That is my big question. Is XML/XSLT really the right solution? Using SAX > along with having tags call handlers seems like a pretty powerful way to > get a very cool tool to build powerful templating services. I haven't > decided if XSLT really is worth the effort as it just seems like a > glorified XML (yes; it is indeed) -- what I mean to say, does XSLT really > have any real value since everything it does can be done in Perl. If I got > make handlers for XSLT, too -- then why even use XSLT? Just go back to > plain XML and do it all on my own, no? There's quite a few things that are a lot harder to do with XML in plain perl (especially in SAX) than they are in XSLT. It's really hard to explain this to anyone who hasn't yet learned XSLT's template model, but the simplest thing to describe is that looping back to previous tags is really hard with SAX (you have to use some sort of node caching technique). One thing a lot of people will argue is that XSLT is verbose and ugly. And I totally agree. But get over it. Perl is ugly too. But once you start using XSLT for any length of time you start to realise just why it is designed like it is, and you start to appreciate that design (and this is from someone who has so far designed *two* alternatives to XSLT!). - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9BZcbVBc71ct6OywRAv81AKDMDkWvAOhwY3A0vDlxxHSK7Y6qOACgm3ni VRLe9kmR9i3tDcMJAKr8d7s= =2Xpn -END PGP SIGNATURE-
Re: separating C from V in MVC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 10 June 2002 11:09 pm, Valerio_Valdez Paolini wrote: > On Mon, 10 Jun 2002, James G Smith wrote: > > I'm working on a framework that will use the Mason component as the > > controller, Perl modules as the model, and either Mason components or > > TT templates called from the controller as the view. The view would > > output XML that would then be put through AxKit or similar by the > > autohandler to add style information and produce HTML or whatever > > format we needed. > > It seems perfect for mod_perl2. Really interesting, xml appears to be > the final destination for most of us, even if now i prefer objects. There's no conflict between using XML and using Objects if you're using AxKit. Especially thanks to Simon Cozen's nice new taglib. - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9BSVWVBc71ct6OywRAtMWAJ94l9mq+ZMWduAMHRD81mHV+a0V7gCgg/bP jPXqIBNKQD64RDnDRLatSBM= =wH5R -END PGP SIGNATURE-
ANNOUNCE: AxKit 1.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 AxKit 1.6 is out. I'll save you all the hoopla in the announce in case people are subscribed to both this list and the AxKit list. Instead here's a link: http://axkit.org/cgi-bin/ezmlm-cgi?3:mss:4164:gckddipdnjdnhmddncgd> Enjoy ;-) - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9BQqEVBc71ct6OywRApseAJ0akqORDCRab8v3hjUwd5PnGQ6mowCdFzex 9Zimn3OtckMkQ4l0jGJDvVE= =s0D/ -END PGP SIGNATURE-
Re: separating C from V in MVC
On Fri, 2002-06-07 at 03:15, Rob Nagler wrote: > Agreed. Perl is good at text manipulation. It is imiho superior to > XSLT in all spaces which XSLT claims to solve. Once you have an XML > parse tree in Perl, it's trivial to write a translator to any format > more correctly than XSLT. My favorite example is XML to CSV. Every > example I've seen in XSLT is cumbersome and wrong. You'd think it > wouldn't be hard, but try it. ;-) XSLT is an XML to XML transformation tool. Seems fairly obvious to me it's not going to do XML to CSV very well. For that you use SAX. I disagree with you in all uses of transforming an XML tree into another XML tree. Right tool for the job, as always. Matt.
Re: Confusion: Perl/mod_perl ????
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 31 May 2002 4:09 am, Stas Bekman wrote: > Actually the new site (which should be released realy soon now) has a > nice and easy intro to mod_perl (thanks to Bill Moseley and others who > helped): > > http://perl.apache.org/release/start/index.html > > So Jeff, you may want to start from this URL first. Also a really good read is Kip Hampton's mod_perl intro on take23: http://take23.org/whatis_mod_perl.xml - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE89xfoVBc71ct6OywRAsluAJ4p7MesbitTOdry4XZWWW/aVp6sGACg1uPe Kc8RbHplc8IJ9AhIoz6zP6w= =vzGh -END PGP SIGNATURE-
Re: [OT] Re: "back-tracking"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 28 May 2002 12:51 am, Andrew McNaughton wrote: > > See: > > Combinatorial Algorithms > > Nijenhuis and Wilf > > Academic Press > > 0-12-519260-6 (1975) > > P 240 > > I've got a different problem. I want to auto-link phrases which appear in > a dictionary, but I need to do some pre-processing on candidate phrases > before checking for them in the dictionary (removing line breaks and > punctuation, doing stemming, etc.) If i get a match i want to put an > tag around the phrase. > > Seems like it shouldn't be too hard, but which ever way I go at it it > feels like a messy kludge. Any suggestions? Is the book referenced above > going to help with this one? > > Probably this is off topic. Reply to me personally, and I'll forward to > anyone who asks for it. One of the best books for this kind of thing is "Mastering Algorithms with Perl". It's got some excellent sections on string matching, stemming, and the like. Details at http://www.oreilly.com/catalog/maperl/ - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE88ykxVBc71ct6OywRAie/AKCFypNHvtr8V37FFJX5w7ipuFaw0gCg5nCZ n3twYWvDWrseBOsuSAk2dlM= =u9KU -END PGP SIGNATURE-
Re: Strange subrequest dir_config issue
On Thu, 23 May 2002, Geoffrey Young wrote: > Matt Sergeant wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > This is just a heads up on something I've not seen documented in either the > > Eagle book or in the Cookbook (at least not that I can find). > > > > If you create a subrequest via $r->lookup_file(), the per_dir_config entry > > doesn't seem to be created. If you use $r->lookup_uri(), it's fine. This can > > be an issue for people with complex applications and configurations trying to > > find out why $sub->dir_config() might not be returning what they expect. > > > > Took me a while to figure this one out - just thought others might like to > > know. > > > well, I hadn't thought about it until now, but actually that makes sense to me (as >it's > early in the morning here :) > > mod_perl just uses r->per_dir_config for $r->dir_config, so it's relying on Apache's > merging behavior wrt lookup_file() and lookup_uri(). one of the things that >lookup_uri() > does that lookup_file() does not do is call location_walk, which merges >per-directory configs. > > I think this makes sense, since a single file can be served by multiple > containers, and with lookup_file() you're essentially telling Apache that you >already know > the filename (sans the translation phase) and you don't really need to know how it >relates > to the incoming URI. both lookup_file() and lookup_uri() call the and > > merging routines, so I would expect that calling lookup_file() on files governed by >those > directives would merge just fine. > > actually, I ran the below test against my perl-bin/ and cgi-bin/ setups (where >perl-bin is > a + Alias and cgi-bin is a + ScriptAlias) and it works as I >suspected. > > does this help? Well it all made sense to me anyway - I just thought it should be documented ;-) -- <:->Get a smart net
Strange subrequest dir_config issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is just a heads up on something I've not seen documented in either the Eagle book or in the Cookbook (at least not that I can find). If you create a subrequest via $r->lookup_file(), the per_dir_config entry doesn't seem to be created. If you use $r->lookup_uri(), it's fine. This can be an issue for people with complex applications and configurations trying to find out why $sub->dir_config() might not be returning what they expect. Took me a while to figure this one out - just thought others might like to know. - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE86ryEVBc71ct6OywRAkdkAKDR4kAQWpcy0voSgDfnN+Emo843vQCdGh4n BswYva0r+TTJiSlN8xG0KCg= =+DU7 -END PGP SIGNATURE-
Re: Memory Leaks
On Monday 20 May 2002 9:30 pm, Gregory Matthews wrote: > I too thought of setting a cron job to restart the server once per day in > order to keep the memory "fresh". > > In a production environment, are there any downsides to doing this, i.e., > server inaccessibility, etc..? It's very rare to have a site that can't cope with just a few seconds downtime. Most users won't even notice, save for some slight delay in getting their request through. Users tend to be pretty used to trying again in this world of "reliable" computing. Matt.
Re: Memory Leaks
On Mon, 20 May 2002, Mark Fowler wrote:
> On Mon, 20 May 2002, Matt Sergeant wrote:
>
> > if ($@ && $@->isa('Exception::DB')) {
> >debug "Exception: $@";
> >$um->dbh->rollback;
> > }
> >
> > (note: if you expect all exceptions to be references like this, you had
> > better have a $SIG{__DIE__} handler installed to bless non-blessed
> > exceptions before re-throwing them
>
> Can't you just use UNIVERSAL's ISA method directly?
>
>if (UNIVERSAL::isa($@,'Exception::DB')) {
>
> This of course might fail if you got the string "Exception::DB" or
> likewise back as an error message.
>
> Alternativly, check if it's blessed
>
>use Scalar::Util qw(blessed);
>
>if (blessed($@) && $@->isa('Exception::DB')) {
Yeah, I know all the tricks. Ultimately it's a matter of how ugly you want
your code to get, and how many external modules you want to rely on (I
believe Scalar::Util is going to be part of 5.8 though).
--
<:->Get a smart net
Re: Memory Leaks
On Mon, 20 May 2002, F. Xavier Noria wrote:
> On Mon, 20 May 2002 10:15:02 +0100 (BST)
> Matt Sergeant <[EMAIL PROTECTED]> wrote:
>
> : > my $um = UserManager->new;
> : > # ...
> : > try {
> : > $um->write_user($user);
> : > $um->dbh->commit;
> : > } catch Exception::DB with {
> : > my $e = shift;
> : > debug "Exception: $e";
> : > $um->dbh->rollback;
> : > };
> :
> : No. $um is caught in a closure, which could potentially leak.
>
> Wow, thank you, I have that pattern repeated in the code many times.
>
> That is the way I would write that try/catch in Java, where you need to
> have $um in the scope of the try and the catch blocks, what is the right
> way to write that in Perl/Error.pm?
I gave up on Error.pm's try/catch syntax a long time ago - I think it's
hidden closure system combined with perl bugs is just too broken for
production use. Instead I use good old eval:
my $um = UserManager->new;
...
eval {
$um->write_user($user);
$um->dbh->commit;
};
if ($@ && $@->isa('Exception::DB')) {
debug "Exception: $@";
$um->dbh->rollback;
}
(note: if you expect all exceptions to be references like this, you had
better have a $SIG{__DIE__} handler installed to bless non-blessed
exceptions before re-throwing them - ask me if you need an example of
that)
--
<:->Get a smart net
Re: Memory Leaks
On Mon, 20 May 2002, F. Xavier Noria wrote:
> On Sun, 19 May 2002 23:34:24 -0400
> "Perrin Harkins" <[EMAIL PROTECTED]> wrote:
>
> : Leaks are caused by circular references, the string form of eval (at
> : least it used to leak a little), nested closures (sometimes created
> : accidentally with the Error module)
>
> I am using the Error module in my current project, what kind of
> constructs should one avoid? Is this safe?
>
> my $um = UserManager->new;
> # ...
> try {
> $um->write_user($user);
> $um->dbh->commit;
> } catch Exception::DB with {
> my $e = shift;
> debug "Exception: $e";
> $um->dbh->rollback;
> };
No. $um is caught in a closure, which could potentially leak.
--
<:->Get a smart net
Re: Apache::Leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 20 May 2002 2:47 am, Gregory Matthews wrote:
> Hello again.
>
> Is Apache::Leak the easiest/best module to use for both detecting AND
> allowing us to find the source of a memory leak in mod_perl?
No - it's a nightmare.
To debug memory leaks in AxKit, everything is wrapped in eval{}, and I simply
run ab (ships with apache) on my site watching the memory size (in top), and
move a line throwing an exception steadily forward through the code line by
line until the leak reveals itself.
Sounds painful, and it is, but it's a *lot* easier than Apache::Leak, which
reports way too many false positives.
- --
<:->get a SMart net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE86JLuVBc71ct6OywRAh78AJ90I+h4zsp3ecBcmKUoKHPb1EaNQgCgsFxK
ZmbS8TEvbnbLTEsknbQ10Zk=
=nJBs
-END PGP SIGNATURE-
Re: we need mod_perl banners
On Tuesday 14 May 2002 4:12 pm, Stas Bekman wrote: > Nobody has volunteered to lead the modperl banners effort, so if you are > an artist or know someone who is and willing to help please send the > banners to me. > > Approx Banner Spec: > --- > Format: PNG > Dimensions: 468x60 and 150x40 (pixels) > Size: about 10k. > > BTW, we still don't have a button derived from the winner logo! > should be 88x31px or something like that. http://take23.org/modperl.svg I'm surprised nobody has taken a snapshot of it yet to use as a banner or button (it's resizable - do a view-source for some details). Matt.
Re: we need mod_perl banners
On Tuesday 14 May 2002 4:12 pm, Stas Bekman wrote: > Nobody has volunteered to lead the modperl banners effort, so if you are > an artist or know someone who is and willing to help please send the > banners to me. > > The story: > -- > Some people want to advertise mod_perl on their sites. We need banners > for that. Your help is appreciated. > > Approx Banner Spec: > --- > Format: PNG > Dimensions: 468x60 and 150x40 (pixels) > Size: about 10k. > > BTW, we still don't have a button derived from the winner logo! > should be 88x31px or something like that. I made SVG that was perfect for the button. I'm not sure why nobody took a snapshot of it. http://take23.org/modperl.svg Matt.
Re: XML::LibXSLT / Apache / MOD_Perl Segfaults
D. Hageman wrote: > I am having some issues utilizing XML::LibXSLT into a mod_perl application > I am working on. The problem displays itself as a segfault on server > startup. The setup I have is a standard RedHat 7.2 box with the following > updated packages: > > apache 1.3.23 > mod_perl 1.26 > libxml2 2.4.21 > libxslt 1.0.17 > perl 5.6.1 > > The CPAN modules are all the latest as of today. The test is just a > simple perl section with: > > > use XML::LibXSLT; > It's probably something to do with the BOOT section in LibXSLT. Just don't load it that way - you're not winning much by trying to make it shared anyway (because it's mostly XS/C code, rather than perl code). Matt.
ANNOUNCE: AxKit 1.5.2
AxKit 1.5.2 is out. Minor bug fixes and small feature changes. http://axkit.org/ - Allow AxKit to handle directory requests. - Fixed all Language modules to return 200/OK - Added AxIgnoreStylePI directive - Ported AxPoint to use XML::Handler::AxPoint - TaglibHelper taglibs no longer need to have parse_* subs - Added HtmlDoc language module - Fixed strange bug in cached LibXSLT stylesheets -- <:->Get a smart net
PPerl performance example
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In case anyone is interested in PPerl as an alternative where mod_perl might be too hard to get installed, I have done some very *very* simplistic benchmarking to show the performance differences. Here's the script I used: use strict; use Data::Dumper; use CGI; print CGI::header(-type => "text/plain"); print Dumper(\%ENV); Running under three environments: Perl CGI, PPerl CGI, and mod_perl Apache::Registry. The results of the quick benchmark over 30 seconds were: Perl CGI: 3.43 requests/sec PPerl CGI: 32.42 requests/sec mod_perl: 80.85 requests/sec Which is about what I expected. The most interesting figures are the latency figures - pperl is around the same latency-wise as mod_perl, where both blow plain perl CGI out of the water, meaning your users get a *much* better experience. Anyway, just thought you might be interested. Note that PPerl is also really useful with stuff like Mail::Audit scripts. - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzCnCYACgkQVBc71ct6OyzIAQCgnREPK8Bj5RCliooqtWWrX+ab jbgAnRHnQAByunmIIylZA0F3Tq+iDMiU =7U2O -END PGP SIGNATURE-
Re: Throttling, once again
On Friday 19 April 2002 6:55 am, Bill Moseley wrote: > Hi, > > Wasn't there just a thread on throttling a few weeks ago? > > I had a machine hit hard yesterday with a spider that ignored robots.txt. I thought the standard practice these days was to put some URL at an un-reachable place (by a human), for example using something like . And then ban that via robots.txt. And then automatically update your routing tables for any IP addresses that try and visit that URL. Just a thought, there's probably more to it. Matt.
[OT] [ANNOUNCE] PPerl 0.04
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a wee bit off topic, but may still be of interest. PPerl 0.04 has been released to CPAN. What's PPerl you may ask? Well it's a persistent perl interpreter. It's quite similar in many ways to SpeedyCGI, except it doesn't require any modifications to your CGI script or Apache setup except perhaps for the #! line to specifiy pperl rather than perl. The code is simpler than SpeedyCGI (the daemon stuff just uses Perl, rather than C, although the client end is C), so I'm hoping perhaps more people will want to get involved with improving the project (plus SpeedyCGI seems dead). The biggest reason for writing this was actually not for web stuff, but for our anti-virus and anti-spam code at MessageLabs (www.messagelabs.com). Basically perl compile time takes up most of our time to process an email, so we had to do something about it. PPerl is what came out of that, and I was allowed to release it open source. So it may be useful to anyone who has, for example, a cron job, or a mail processing script, or basically anything rather large that they need to speed up. Anyway, do play with it, and let me know what you think, and if you find bugs or anything like that. Cheers, Matt. - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjy71NMACgkQVBc71ct6OywLngCglzRm6f7/JqsXW8Km6+3retTh qxoAoON1dfm9snjZTFjaVMWSaQiiswzQ =I322 -END PGP SIGNATURE-
Re: [OT] [ANNOUNCE] mod_log_sqlite
On Mon, 15 Apr 2002, Perrin Harkins wrote: > Tatsuhiko Miyagawa wrote: > > Announcing new Apache module (written in C): > > > > mod_log_sqlite is an Apache logging module for sqlite database. It > > allows you to log your HTTP stats into sqlite, then you can do queries > > using sqlite's SQL feature (including subselects, views) to HTTP > > statistics. > > The SQLite FAQ seems to suggest that SQLite isn't very good at parallel > read/write situations: http://www.hwaci.com/sw/sqlite/faq.html#q6 > > Have you seen any problems so far? Is that any different to how it is with file logging? PS: Taso: you sent to [EMAIL PROTECTED], which Ask seems to have setup to redirect to the right address. -- <:->Get a smart net
Re: Content management systems
On Tuesday 09 April 2002 7:53 am, Matthew Watson wrote: > Heya. > > I was wondering if there are any content management systems around for > modperl , i'm after a similar kind of thing > as postnuke for php. I'd much rather something 'out of the box' as I don't > have time to develop a system from scratch mysql. For community sites, use Slash - the engine behind slashdot (http://www.slashcode.com) - there's even a book about it. For large scale content management - like for a news site - check out Bricolage (http://bricolage.thepirtgroup.com/). Bricolage is built upon some of the ideas of the content management system behind Salon.com (though they seem to be talking of replacing it with a Java/Cocoon based system). -- <:->get a SMart net
Re: take23.org 500 internal server error (probably OT)
On Monday 08 April 2002 7:44 pm, David Nelson wrote: > Hello all, > > Thanks to everyone for helping promote open source! > What a great feeling it is to be a part of this > movement. http://www.take23.org is down due to an > internal server error at the moment. If anyone knows > who maintains this and can email them, they'd probably > appreciate it. Sorry if this is very off topic. Fixed. Thanks for the heads-up. > Since I'm posting, I'll share one more quick question. > Does anyone know how to license software as GPL but > have it only be able to be used by non-profit > companies? Try the Aladdin Public license. This is what pdflib (www.pdflib.com) uses. -- <:->get a SMart net
Re: mod_perl Cook Book
On Fri, 5 Apr 2002, Rasoul Hajikhani wrote: > Hello folks, > Has anyone purchased the mod_perl cook book from this list? If so, what > do you think of it? Is it a good buy? Appreciate feed back. I have two copies, as the one at work keeps getting borrowed. I would say it's different to the Eagle book - it takes a different tack (which is kinda the point). I find both books useful - the Eagle book for explaining the Apache request cycle very clearly, and the Cookbook for explaining some of the nuances of mod_perl very clearly. Basically the Cookbook is much more about solving specific problems than the Eagle book, and as such is much more useful long term and short term, and I also found the explanations a bit clearer in the Cookbook. So I'd get both, but the Cookbook first if you're new to mod_perl, and then the Eagle book if you're still confused about some issues. I promised Geoff I would do a full review, and I'm doing an OS upgrade this weekend, so perhaps I'll get a chance to go over the bits of the book I've missed so far and post the review somewhere. -- <:->Get a smart net
SVG version of logo
Animated version of the new mod_perl logo: http://take23.org/modperl.svg If you want a button, download it and change the width/height attributes to 100 x 22 (or smaller/larger as appropriate). -- <:->Get a smart net
Re: [ANNOUNCE] The New "mod_perl" logo - results now in...
On Mon, 18 Mar 2002, Steve Piner wrote: > I definitely agree with this. I'd like to see some more colour > variations (maybe just background colours even) to allow it to fit into > a site's design better. > > Jonathan asked whether we should have just one button, or several. I'd > say just one theme, with several variations as mentioned above. This is dead easy to do with the SVG version. Feel free to hack around with it. -- <:->Get a smart net
Re: [ANNOUNCE] The New "mod_perl" logo - results now in...
OK, here's my attempt at SVGing the logo. Works in Adobe's SVG viewer (Linux and Windows). I'll work on animating it next (making the cog spin). -- <:->Get a smart net mod_perl logo Michael Demers' mod_perl logo mod perl
RE: [ANNOUNCE] The New "mod_perl" logo - results now in...
On Fri, 15 Mar 2002, Jonathan M. Hollin wrote: > :: Is the logo available in a vector file format so that we can > :: easily make > :: scaled copies of it? Or are we restricted to the pixel banners that > :: currently exist? > > All I have is non-vector JPEG. Again, I'll ask Michael. If we can find out what the font is, I'd enjoy trying to do an SVG version (I just bought an SVG book, so I'm enjoying playing). -- <:->Get a smart net
Re: performance testing - emulating real world use
On Tue, 12 Mar 2002, Jauder Ho wrote: > > Another application (commercial) is Mercury Interactive's LoadRunner. It > actually records events and plays it back on "load generator" machines. > It's fairly complex, has LOTs of knobs to turn and can load test quite a > bit more than just web apps, I use it to load test/benchmark Oracle 11i > for instance. The software is not cheap but definitely worth looking into > if you are serious about testing. (www.merc-int.com) > > They also sell something called ActiveTest which may be more suited to a > web applications. In this case, they will test your site for you using > their hardware at a colo site. Before anyone even looks into this, be warned they quoted me £50,000 once for LoadRunner. Needless to say I was flabbergasted (though their software did look kinda cool). -- <:->Get a smart net
Re: ANNOUNCE: Apache::Watchdog::RunAway v0.3
On Fri, 1 Mar 2002, Stas Bekman wrote: > > The uploaded file > > Apache-Watchdog-RunAway-0.3.tar.gz > ^^^ > * this module has spent enough time in alpha/beta incubator => going 1.0. ^^^ So which is it? ;-) -- <:->Get a smart net
Re: XML::Twig
On Thu, 28 Feb 2002, Stathy G. Touloumis wrote: > Hi, > > Has anyone experienced problems when using the XML::Twig with mod_perl? > Everything works fine outside a mod_perl environment but when attempting to > perform the same functionality in mod_perl the child process seg faults even > when using 'safe_parse' which is supposed to wrap the parsing in an 'eval' > and return an error code instead of dying. It's the built in expat bug. Upgrade XML::Parser to 2.30, then upgrade Apache to latest. The problem should go away. -- <:->Get a smart net
Re: choice of mod_perl technology for news site
On Wed, 6 Feb 2002, Drew Taylor wrote: > You should take a look at Bricolage (http://bricolage.thepirtgroup.com/). > It's a relatively new, but comprehensive, CMS that is based on Mason & > mod_perl. I think it supports most of the things you mentioned below, but > you should ask the developers to be sure. > > If you talk w/ Matt, he'll be sure to hawk AxKit. But then that's Matt. And > AxKit really is cool stuff. :-) Well I'd rather recommend whatever works for people. Bricolage certainly seems full featured, and it looks easy enough to add XSLT support to it, though I haven't had chance to download and try that yet. As far as AxKit based CMS's go, well I was writing one but it died in the dot-bomb as I became an "Anti Spam and Virus Technologist" (which is actually a really nice change from web hacking). As far as other CMS's, Robin has already mentioned XIMS and his Tesserra, but forgot about this one: http://www.callistocms.com/ which simply blew my mind looking at the graphics. I guess I'm easily pleased ;-) I don't know if that one is going to be free or not though. -- <:->Get a smart net
Re: modperl growth
On Sat, 2 Feb 2002, Robin Berjon wrote:
> Hi,
>
> I thought that some of you might find this graph interesting:
>
> http://www.securityspace.com/s_survey/data/man.200201/apachemods.html?mod=cGVybA==
>
> For some reason, in December, it would seem that modperl just jumped ahead in
> market share (from 13% to nearly 20%). So given that people here are
> occasionally given to gloom and doom descriptions of the Perl/mod_perl world
> ("there aren't as many people as before", "the Java folks are taking over",
> etc.) I'd like to take this growth as well as modperl's general well doing
> (19.78% is a *huge* amount of people -- 600.000 servers, a "fifth of the
> internet") as a very good sign that modperl is alive, kicking, and doing very
> well. Kudos to all ;-)
Wow, bizarre. Not sure why but the AxKit list has seen a massive spurt in
traffic lately too. Perhaps due to the migration to xml.apache.org (well,
just a link at the moment), but perhaps due to the above?
However I'm always skeptical of such massive changes - perhaps more likely
is a change in SecuritySpace's methodology?
--
<:->Get a smart net
Re: [OT] Re: mod_perl Developer's Cookbook (and Amazon)
On Sat, 2 Feb 2002, Paul Lindner wrote: > On Sat, Feb 02, 2002 at 10:03:09AM -0600, Mike808 wrote: > > > Joe Brenner wrote: > > > > Spend only $4 more, and you too can show your disgust for > > > > software patents. > > > > Worth every penny. > > I'm against frivolous patents myself. It harms the industry and could > even be detrimental to mod_perl or Apache if either is found to > infringe upon such a patent. Do you mean like this one from Sun: http://l2.espacenet.com/dips/viewer?PN=WO0163481&CY=ep&LG=en&DB=EPD It's a patent covered directly by two Apache technologies: AxKit and Cocoon. The ASF have however taken steps to get reassurance from Sun they won't enforce this against them, and Apache has the prior art anyhow. Just another example of how terrible the USPO is. -- <:->Get a smart net
Re: Apache::args vs Apache::Request speed
On 1 Feb 2002, Joe Schaefer wrote: > Would someone PLEASE volunteer to try to compile and test > apache+mod_perl & libapreq on OS/X using the experimental > code I posted there? Even if you can't get it working, > ANY feedback about what happened when you tried would be > VERY helpful. OK, if someone can communicate with me in private, seriously dumbed down details, I can try this. I'm a libapreq committer, and have sourceforge farm access, so I'll do my best there - though last time I tried I couldn't get onto their OSX box... -- <:->Get a smart net
mod_perl Developer's Cookbook
My copy just arrived! I'll try and get through most of it as fast as I can and post a review. Congrats Geoff, Paul and Randy. Looks great at first glance. -- <:->Get a smart net
Re: Dynamically serving an .htaccess file with mod_perl
On Mon, 28 Jan 2002, Michael A Nachbaur wrote: > Hello all, > > Does anyone know of a way that I can server the contents of an .htaccess > file dynamically? I know Apache checks the request directory (and all > directories above it) for an .htaccess file before serving a file request, > but there is no mention of how it goes about loading that file. Not that I know of, but you can hook in there custom parsing code. It's way too complex to explain though, so I suggest you get the eagle book which goes into details on it. -- <:->Get a smart net
Re: performance coding project? (was: Re: When to cache)
On 25 Jan 2002, David Wheeler wrote: > On Fri, 2002-01-25 at 09:08, Perrin Harkins wrote: > > > > > It's much better to build your system, profile it, and fix the bottlenecks. > > The most effective changes are almost never simple coding changes like the > > one you showed, but rather large things like using qmail-inject instead of > > SMTP, caching a slow database query or method call, or changing your > > architecture to reduce the number of network accesses or inter-process > > communications. > > qmail-inject? I've just been using sendmail or, preferentially, > Net::SMTP. Isn't using a system call more expensive? If not, how does > qmail-inject work? With qmail, SMTP generally uses inetd, which is slow, or daemontools, which is faster, but still slow, and more importantly, it anyway goes: perl -> SMTP -> inetd -> qmail-smtpd -> qmail-inject. So with going direct to qmail-inject, your email skips out a boat load of processing and goes direct into the queue. Of course none of this is relevant if you're not using qmail ;-) -- <:->Get a smart net
RE: handling eval in ePerl
> -Original Message-
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
>
> > My problem is that die works fine as such but it conks out if done
> > inside a eval.
>
> Okay, I missed the part about eval() before. Take a look at this code
> from Parse::ePerl::Evaluate() :
> local $SIG{'__DIE__'} = sub { $error .= $_[0]; };
Yuck. People really need to stay away from $SIG{__DIE__} unless they
*really* know what they're doing.
Matt.
This e-mail has been scanned for all viruses by Star Internet. The service is powered
by MessageLabs. For more information on a proactive anti-virus service working around
the clock, around the globe, visit: http://www.star.net.uk
Re: handling eval in ePerl
On Mon, 21 Jan 2002, Mithun Bhattacharya wrote:
> Perrin Harkins wrote:
>
>
> Umm I didnt mean to offend anyone in my previous posting - I did say I
> probably hadnt presented my situation properly.
I don't think anyone was offended. Perrin was just trying to help you see
why people might not have replied. That's what I got from the tone anyway.
> > The Apache::ePerl code is very simple, and I suggest you read it at some
> > point. It attempts to eval() your code, and does the behavior you saw
> > if it fails (which is what happens when your script does a die()). I
> > don't think you can change that without changing the code, but that's
> > pretty easy to do.
>
> My problem is that die works fine as such but it conks out if done
> inside a eval.
>
> --
> <%
> die "blah blah blah";
> %>
> --
>
> redirects me to the default error page.
>
> --
> <%
> eval {die "blah blah blah";};
> %>
> --
>
> on the other hand says the following.
>
> --
> Apache::ePerl
> Version 2.0214
>
> ERROR:
> Error on evaluating script from P-code
>
> Contents of STDERR channel:
>
> blah blah blah at //test.html line 2.
> --
It looks to me like the generated code that ePerl is trying to eval is
bad. That seems like it's most likely this is an actual ePerl problem, and
so the only thing I can suggest is you hack the ePerl code to actually
display $@ when the evaluation of the "script from P-code" occurs (why on
earth aren't they doing that already??). Also I suggest while you're in
there, have it print the script to STDERR before doing the eval, so you
can check the error log and see what ePerl thinks your parsed script looks
like.
> I am not sure why that might be considered acceptable response but it
> really makes my code a lot more messier trying to circumvent that.
>
> If I could have fixed Apache::ePerl I wouldnt be asking the question
> here - I usually dont go around asking questions to show people how much
> I know about anything. I am not asking to be spoonfed or something but
> if there is something which can be done without changing the
> Apache::ePerl code I would opt for that. It feels like being told to
> change gcc's code if my C code is not working :) - yah both of them are
> written in C .
The difference being that gcc is maintained, so you might stand a cat in
hell's chance of some help from the authors or getting a bug fix.
Unfortunately ePerl isn't maintained, so you have to open the bonnet (hood
to USians) and fix things yourself.
--
<:->Get a smart net
Re: RFC: Exception::Handler
On Mon, 14 Jan 2002, Rob Nagler wrote:
> > I'm afraid I don't get it - isn't it what the "finally" functionality
> > in Error.pm (CPAN) does ?
> >
> > try {
> > stuffThatMayThrow();
> > } finally {
> > releaseResources();
> > };
>
> One reason for exceptions is to separate error handling code from the
> normal control flow. This makes the normal control flow easier to
> read. If releaseResources() is to be called whenever an exception
> occurs, then it is advantageous to eliminate the extra syntax in the
> class's methods and just have releaseResources() called whenever an
> exception occurs and the object is on the stack.
>
> Our exception handling class searches down the stack looking for
> objects which implement handle_die(). It then calls
> $object->handle_die($die), where $die is the exception instance. This
> increases the cost and complexity of exception handling, while
> decreasing the cost and complexity of normal control flow. It also
> ensures that whenever the object is involved in an exception,
> handle_die() is called giving it an opportunity to examine the
> exception and clean up global state if necessary.
Might be a fun thing to try out using the mysterious PROPOGATE method (try
it - implement a PROPOGATE method in your exception class, and watch for
when it gets called).
--
<:->Get a smart net
Re: formmail spammers
On Sat, 12 Jan 2002, Perrin Harkins wrote: > > http://www.spamassassin.org/ > > > > Without a doubt, the best anti-spam solution around. > > That looks great for solving the problem on my own account, but the > larger problem is that there are all of these insecure installations of > formmail.pl out there that spammers are using to send tons of mail. > It's like having an open relay. > > A program to check for these on Google and then alert the webmaster at > each offending site could be a really good thing. Right, and point them to NMS for a replacement too. -- <:->Get a smart net
Re: Exception::Handler
On Sat, 12 Jan 2002, Tatsuhiko Miyagawa wrote:
> On Fri, 11 Jan 2002 17:34:30 -0600 (CST)
> Dave Rolsky <[EMAIL PROTECTED]> wrote:
>
> > > You would have:
> > > try {
> > > code;
> > > } catch FooException with {
> > > code for FooExceptions;
> > > } catch BarException with {
> > > code for BarExceptions;
> > > } otherwise {
> > > };
> >
> > And the fun potential for memory leaks with nested closures.
>
> Matt has an idea for doing this with Filter module, instead of
> nasty closures.
Actually unfortunately I even had code, but it was on my laptop that died.
I may resurrect the project in time for this year's Perl Conference,
provided Tony Blair decides to instigate my vision of a 30 hour day.
--
<:->Get a smart net
Re: RFC: Exception::Handler
On Fri, 11 Jan 2002, Tatsuhiko Miyagawa wrote:
> use Exception::Handler
> MyException => \&my_handler,
> AnotherException => \&another_handler,
> __DEFAULT__ => \&default_handler;
>
> eval { MyException->throw }; # my_handler()
> eval { AnotherException->throw; };# another_handler()
> eval { YetAnotherException->throw; }; # another_handler() : hierarchical
> eval { FooBarException->throw; }; # default_handler()
I don't like this for the same reason I don't like $SIG{__DIE__} - it
promotes action at a distance. In a 1000 line .pm file I *want* to have my
exception catching mechanism next to my eval{} block.
--
<:->Get a smart net
Re: formmail spammers
On Fri, 11 Jan 2002, Perrin Harkins wrote: > > I assume I'm not the only one seeing a rash of formmail spam lately. > > Is THAT what it is? I have a Yahoo mail account which someone has been > sending literally thousands of messages per day to, CC'ing lots of > people on every one, and they all appear to be from some kind of > compromised form mailer script. I'm open to any suggestions. http://www.spamassassin.org/ Without a doubt, the best anti-spam solution around. -- <:->Get a smart net
Re: ANNOUNCE: Bricolage 1.2.0
On 11 Jan 2002, David Wheeler wrote: > On Fri, 2002-01-11 at 01:29, [EMAIL PROTECTED] wrote: > > > Do you provide a demo of Bricolage. Can I expect something similar to > > the Midgard Project on PHP? > > Unfortunately there is no demo of Bricolage at this time. But you can > start reading up on it and see some screenshots at > http://bricolage.thepirtgroup.com/. Looks neat! > I'm not familiar with Midgard, though it looks interesting. What > differentiates Bricolage from other OSS CMSs, however, is its robust > support for configurable workflows. Furthermore, its templates are > written in HTML::Mason or HTML::Template -- that is, Perl. So you have a > complete, robust programming language to work with. Any chance of supporting more template systems in the future, like TT and XSLT? -- <:->Get a smart net
Re: Apache and Perl togheter
On Wed, 9 Jan 2002, Alan Civita wrote: > More information about this error may be available in the > server error log Try reading the text :-) -- <:->Get a smart net
RE: Error log executing scripts?
> -Original Message- > From: Geoffrey Young [mailto:[EMAIL PROTECTED]] > > Magnús Þór Jónsson wrote: > > > > Hello, > > I was wondering if there is any way of making the error log > in Apache to > > execute a script when an error is occurred, perhaps instead > of writing the > > error directly to the log. > > > > For example, if there is a image missing Apache excutes a > script that > > generates a replacement image? > > well, you can do just about anything you want :) > > however, althoughit is possible to intercept the actual errors Apache > (and mod_perl) generates, it is rather complex, and really not the > proper approach here. Really? I would have thought it could make an interesting caching technique - on a 404 you try and generate the file, and store in that slot in the filesystem. A cache cleanup daemon runs to clean out TTL'd files. Warning: don't try and implement this in a commercial application - it's patented by vignette. Matt. This email has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit www.star.net.uk
Re: WYSIWYG Template Editor
On Tue, 1 Jan 2002, Les Mikesell wrote: > >From: "Matt Sergeant" <[EMAIL PROTECTED]> > > > > Does anybody know a template engine, whose templates can be edited with a > > > "WYSIWYG" editor (favourably dreamweaver) as they will look when filled > > > with example data? > > > > If you use XSLT, there's a number of options available to you. Try > > searching a site like http://www.cafeconlech.org/ > > I can't reach that site - is the spelling correct? I'd like to find something > that > would allow non-technical people to write their own templates for pages > that, as they are accessed, fill in variables pulled by a server-side http > request > to an XML data source. To make things even more difficult, I'd like parts > of the resulting page to appear in editable form fields that could be modified > before submitting to yet another location. We have data servers with > commodity > exchange data, and reporters that need to generate stories showing those > values, > sometimes including comments. Some of the layouts never change, but it > would really be best if the reporters could generate and control their own > templates without having to understand all of the details involved. One interesting tool is Xsplit from percussion. You might find it quite interesting. I missed the e off cafeconleche.org, fwiw. -- <:->Get a smart net
Re: WYSIWYG Template Editor
On Tue, 1 Jan 2002, Joachim Zobel wrote: > > Happy New Year. > > Does anybody know a template engine, whose templates can be edited with a > "WYSIWYG" editor (favourably dreamweaver) as they will look when filled > with example data? If you use XSLT, there's a number of options available to you. Try searching a site like http://www.cafeconlech.org/ -- <:->Get a smart net
ANNOUNCE: AxKit 1.5
AxKit 1.5 is now available for download from both AxKit.org, and soon CPAN mirrors worldwide. This is a major upgrade, so please use caution when upgrading live servers, as major internal parts of AxKit have changed with this release. Most significantly, a large amount of code has been migrated to C, and some parts of the code have been migrated to use libxml2, which you should install prior to installing AxKit for optimum performance. It is now possible if you have libxml2 installed to run AxKit entirely without XML::Parser, which will help for people who can't recompile Apache (to remove the included expat). There have been many performance improvements in this release, too many to mention. Perhaps the most significant though is that AxKit is now a first class Apache handler (although it still requires mod_perl), so you can do: "SetHandler axkit", rather than have to use PerlHandler. This is a performance win, and will help if we ever need to move away from mod_perl to being a pure Apache module. For a full list of changes, please consult the axkit-users mailing list archives. Details of which are at http://axkit.org/mailinglist.xml Changes since AxKit 1.4_86 (beta): AxPoint added the ability to do bullet point transitions Fixed LibXSLT relative files with document() Fixed some core caching and delivery bugs Fixed MANIFEST missing files -- <:->Get a smart net
Re: Fast template system
On Sun, 30 Dec 2001, Ryan Thompson wrote: > Dave Hodgkinson wrote to Ryan Thompson: > > > Ryan Thompson <[EMAIL PROTECTED]> writes: > > > > > Any thoughts? > > > > You really have to ask?!!! > > Yes!! :-) > > I've tried or at least taken a critical look at most of the template > systems out there, and they are either far too simple (i.e., variable > expansion only), far too complex, or use constructs/syntax that break > HTML validation. You want validation? Use XSLT. -- <:->Get a smart net
RE: Tips & tricks needed :)
> -Original Message-
> From: Tatsuhiko Miyagawa [mailto:[EMAIL PROTECTED]]
>
> On Wed, 19 Dec 2001 16:01:22 -
> Matt Sergeant <[EMAIL PROTECTED]> wrote:
>
> > Actually I was wondering about writing an Apache::Singleton
> class, that
> > works the same as Class::Singleton, but clears the
> singleton out on each
> > request (by using pnotes). Would anyone be interested in that?
>
> Like this? (using register_cleanup instead of pnotes)
>
>
> package Apache::Singleton;
>
> use strict;
> use vars qw($VERSION);
> $VERSION = '0.01';
>
> use Apache;
>
> sub instance {
> my $class = shift;
>
> # get a reference to the _instance variable in the $class package
> no strict 'refs';
> my $instance = "$class\::_instance";
>
> unless (defined $$instance) {
> $$instance = $class->_new_instance(@_);
> Apache->request->register_cleanup(sub { undef $$instance });
> }
>
> return $$instance;
> }
>
> sub _new_instance {
> bless {}, shift;
> }
Yeah, just like that. Why don't you wrap it up and stick it on CPAN? Saves
me another module :-)
Matt.
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
RE: Tips & tricks needed :)
> -Original Message- > From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > > > Actually I was wondering about writing an Apache::Singleton > class, that > > works the same as Class::Singleton, but clears the > singleton out on each > > request (by using pnotes). Would anyone be interested in that? > > This sounds a bit like Object::Registrar. No, it's nothing like Object::Registrar. It's like Class::Singleton. Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
RE: Tips & tricks needed :)
> -Original Message- > From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > > > ALWAYS reinitialize $Your::Singleton::ETERNAL on each query! > > mod_perl will *NOT* do it for you. > > If you want a per-request global, use $r->pnotes() instead of > a standard > perl global. Then mod_perl *WILL* do it for you. Actually I was wondering about writing an Apache::Singleton class, that works the same as Class::Singleton, but clears the singleton out on each request (by using pnotes). Would anyone be interested in that? Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Re: mod_perl site challenge: proposal to use ASF site design
On Mon, 17 Dec 2001, Thomas Klausner wrote: > > I propose that we simply use a site design that is the uniform > > "psudo-standard" for the Apache Software Foundation. A number of ASF > > projects are using this site design: > > http://www.apache.org/ > > http://httpd.apache.org/ > > http://jakarta.apache.org/ > > http://www.apache.org/foundation/ > > I just took a brief look at those sites, and I think that they are > structurally somewhat different from the (new) mod_perl site. All those > sites are rather flat, i.e. there are no deep nested hierarchies like at the > mod_perl site (e.g.: Home / Documentation / mod_perl Developer's guide / ) Interestingly this has come up on the Cocoon-dev list also, who are looking to update the design of xml.apache.org, in such a way to allow deep navigation. Interested parties should probably check that list (try marc.theaimsgroup.com, subject "Forrest"). -- <:->Get a smart net
Re: mod_perl vs. C for high performance Apache modules
On Fri, 14 Dec 2001, Jeff Yoak wrote: > All, > > I wasn't sure what volume of response to expect when I originally > wrote. Thank you all for the comments that you all are making. They are > helping. Given that the response is fairly high, I'm waiting for stuff to > roll in rather than replying to each of you. Don't think it is falling on > unappreciating ears. :-) > To respond to a few recurring comments / questions: > > Me? I've spent most of the last four years working on mod_perl-based stuff > and most of the last eight working with Perl. Actually I've worked with > folks who were involved with some of the projects you've mentioned, having > been at idealab!, a parent of eToys and CitySearch. One of the original > (THE original?) developer at CitySearch was probably the most helpful > mentor / teacher I've ever worked with. I programmed in C a lot early in > my career, but at this point I couldn't write anything substantial without > brushing up, and frankly wouldn't care to. It just isn't as fun to work > with C. But then, the argument, "But if you used C, you wouldn't get to > work with ME!" may not convince some of these people with their values all > screwed up... ;-) Actually that would be my argument. When you're getting investors in, the primary thing they should be looking to buy into is the quality of the people there, not necessarily the code, because only one out of those two can be fixed easily (even in our current times, totally replacing a programming team is a difficult thing to do). I write C. I write Perl. And I combine them both to good effect. But, I wouldn't even consider writing anything but time critical routines in C - I do as much as possible in Perl for the following reasons: - It's fast enough. - It's safer. - It has a built in test harness (Test::Harness). - It's more fun. - It's faster to develop in. - It's OO, and that saves me time and effort. - It has an infinitely better community than C. The last point is probably my favourite, though probably means bugger all to an investor. -- <:->Get a smart net
RE: Can't call Apache::Request->new()
I think I know what's happening here. Your script is running as a CGI, not
as mod_perl. Check:
print "not " unless $ENV{MOD_PERL};
print "running under mod_perl\n";
Matt.
--
<:->Get a smart net
> -Original Message-
> From: Paul Makepeace [mailto:[EMAIL PROTECTED]]
> Sent: 14 December 2001 08:53
> To: Ged Haywood
> Cc: Anand R; [EMAIL PROTECTED]
> Subject: Re: Can't call Apache::Request->new()
>
>
> On Fri, Dec 14, 2001 at 08:31:26AM +, Ged Haywood wrote:
> > Hi there,
> >
> > On Fri, 14 Dec 2001, Anand R wrote:
> >
> > > The Request Object contains info sent to the server in
> the client's request.
> > [snip]
> > > Maybe this should not a big problem,U just have to have a
> look at the
> > > Apache Doc.
> >
> > I think he's trying to say
> >
> > perldoc Apache::Request
>
> Hmm, I was hoping I was way beyond that!
>
> Perhaps I'm not being clear -- I'm use'ing a module and calling a
> documented method and then perl is claiming the module isn't loaded. I
> showed a command line that demonstrated this (& that the module is
> installed) and then said it also happened when under mod_perl. To go
> into even more detail, here is how I'm calling it under mod_perl. I'm
> new to this so quite possibly the mistake's somewhere here...
>
> httpd.conf:
>
>
>SetHandler perl-script
>PerlHandler Apache::Registry
>Options +ExecCGI
>PerlSendHeader On
>
>
>
> apr.cgi:
>
> #!/usr/bin/perl -Tw
> use strict;
>
> use Apache::Request;
>
> my $r = shift;
> my $apr = Apache::Request->new($r);
> my @params = $apr->param;
>
> print < Content-type: text/plain
>
> @params;
> HTML
>
>
> And sho' nuff ...error.log contains,
>
> Can't locate object method "new" via package
> "Apache::Request" (perhaps you forgot to load
> "Apache::Request"?) at /home/wwwrp/perl-bin/apr.cgi line 7.
> [Fri Dec 14 00:43:14 2001] [error] [client 172.30.0.3]
> Premature end of script headers: /home/wwwrp/perl-bin/apr.cgi
>
> > :)
> >
> > 73,
> > Ged.
> >
> > PS: Cute email address Paul.
>
> Heh thanks -- no prizes for guessing which device file x10.com@
> goes to :-)
>
> 55,
> Paul
>
> --
> Paul Makepeace ...
http://paulm.com/
"What is the meaning of life? The unforgiven."
-- http://paulm.com/toys/surrealism/
This email has been scanned for all viruses by the Star Internet Virus
Screen.
The service is provided in partnership with MessageLabs, the email security
company.
For more information on a higher level of virus protection visit
www.star.net.uk
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
RE: Any good WebMail programs?
I've used SqWebMail with good success, it certainly seems to have all the features you wish for. Though I'd like to try Wing too to compare it. Matt. -- <:->Get a smart net > -Original Message- > From: Medi Montaseri [mailto:[EMAIL PROTECTED]] > Sent: 13 December 2001 06:44 > To: [EMAIL PROTECTED] > Subject: Any good WebMail programs? > > > > I can use a primer on researching WebMail programs with the following > criterian: > > - Linux based > - Free > - Preferably in Perl > - Modularized Authentication subsystem (ie could hook up adapters to > check with LDAP or RDBMS, though Linux can do that also) > - Apache support > - IMAP support > - Multi-lingual (can be a phase II) > - As feature-rich as possible (can be a phase II) > > Please note that I'm not looking for a service, I'm looking for the > software itself. > > Thanks > > -- > -- > --- > Medi Montaseri [EMAIL PROTECTED] > Unix Distributed Systems EngineerHTTP://www.CyberShell.com > CyberShell Engineering > -- > --- > > > __ > __ > This email has been scanned for all viruses by the Star > Internet Virus Screen. > The service is provided in partnership with MessageLabs, the > email security company. > For more information on a higher level of virus protection > visit www.star.net.uk > __ > __ > _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
RE: HTML forms and piplining templating systems
> -Original Message- > From: Richard L. Goerwitz III [mailto:[EMAIL PROTECTED]] > > Is AxKit the best of the pipelining breed, though? (I personally > am finding XML to be a ghastly, ugly thing; it all started with > namespaces, which are implemented via attributes in a horribly > kludgy way - and now we're finding new schema mechanisms entering > in, plus complex and unintuitive beasts like XSL. So I wonder just > how slick AxKit can possibly be, given its foundation in these > technologies.) Well AxKit certainly has its flaws (it's almost to the point where I either have to do major re-writes, or a complete re-write, or just work really hard to fix the flaws, as happens with most projects of its kind when you have used them to do serious work), but I can't agree with you that XML is one of them. It's just a syntax for describing data after all, so don't think in terms of the syntax - think in terms of data! That's the biggest problem I have when people start saying "Well, but XML sucks!". I wouldn't necessarily say it's best of breed. For a real "best of breed" I would look towards Cocoon2. But you get what you pay for, so while AxKit might not be as well designed and thought out as Cocoon2, it's a hell of a lot easier to get started with, and continue working with, and it still seems to be faster and more flexible in some ways. Besides, I'm the wrong person to ask ;-) Matt. -- <:->Get a smart net _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
