Re: Apache::AuthCookie login faliure reason
On Fri, Nov 23, 2001 at 04:09:45PM +1100, simran wrote: > What i want is: > > * To be able to give the user a reson if login fails > - eg reason: * "No such username" > * "Your password was incorrect" On Thu, Nov 22, 2001 at 09:26:17PM -0800, clayton wrote: > here is the meat of the matter > send something like this to the $r->subprocess_env > $r->subprocess_env('AuthCookieReason2', 'username invalid!'); yeah, but it depends when and where you do that. I found that if I set subprocess_env in the AuthCookieHandler->authen_cred method, which is where the login credentials get checked, it wasn't visible to the login script - this is because a redirect takes place in between, so a whole new request is started. So I had actually been doing something really dodgy to catch invalid logins, but your mention of setting another cookie gave me the idea of using the session key of the authcookie itself. If you set this to something like 'InvalidLogin' in authen_cred, you can then check for this and set the reason via $r->subprocess_env in AuthCookieHandler->authen_ses_key, before AuthCookie->authenticate wipes the cookie out. Not extensively tested, but seems to work so far :) -carolyn
RE: Apache::AuthCookie login faliure reason
Thanks for your response Clayton. Although unfortunately its not working for me as from what i understand: * When a person has to login (asusming they have no cookie set yet), if they enter the wrong credentials "authen_cred" does a _external redirect_ (aka redirects the browser to go to that url again) - hence subprocess_env is not available from a previous request. If the problem was an incorrect cookie however, the subprocess_env would indeed by handy, as authen_ses_key does an internal redirect, hence you can get the "previous requests" subprocess env... simran. -Original Message- From: clayton [mailto:[EMAIL PROTECTED]] Sent: Friday, 23 November 2001 4:26 PM To: simran Cc: [EMAIL PROTECTED] Subject: Re: Apache::AuthCookie login faliure reason yes its pretty easy one to do, btw: i first found out how by investigating the Apache::AuthCookie code here is the meat of the matter send something like this to the $r->subprocess_env {the name im using is the same as authcookie's with the 2 added} $r->subprocess_env('AuthCookieReason2', 'username invalid!'); then in your login.cgi {or handler or w.h.y.} you can do this: my $error=$r->prev->subprocess_env('AuthCookieReason2') ||$r->prev->subprocess_env('AuthCookieReason') ; or use 'defined' or w.h.y. then you can place $error wherever you please hope that helps simran wrote: > Hi All, > > > > I am having some trouble getting Apache::AuthCookie (version 3 which i > believe is the latest version) to do what want: > > > > What i want is: > > > > * To be able to give the user a reson if login fails > > - eg reason: * "No such username" > > * "Your password was incorrect" > > > > Has anyone else come across the same requirement/issue, and how have > you solved it? > > > > It seems like a difficult one to solve (in a clean way) as the only > way i can think of doing it is either setting > > another cookie (with the auth failure reason) or adding to the URL > query parameters and then reading them > > when displaying the login page... > > > > simran. >
Re: Apache::AuthCookie login faliure reason
yes its pretty easy one to do, btw: i first found out how by investigating the Apache::AuthCookie code here is the meat of the matter send something like this to the $r->subprocess_env {the name im using is the same as authcookie's with the 2 added} $r->subprocess_env('AuthCookieReason2', 'username invalid!'); then in your login.cgi {or handler or w.h.y.} you can do this: my $error=$r->prev->subprocess_env('AuthCookieReason2') ||$r->prev->subprocess_env('AuthCookieReason') ; or use 'defined' or w.h.y. then you can place $error wherever you please hope that helps simran wrote: > Hi All, > > > > I am having some trouble getting Apache::AuthCookie (version 3 which i > believe is the latest version) to do what want: > > > > What i want is: > > > > * To be able to give the user a reson if login fails > > - eg reason: * "No such username" > > * "Your password was incorrect" > > > > Has anyone else come across the same requirement/issue, and how have > you solved it? > > > > It seems like a difficult one to solve (in a clean way) as the only > way i can think of doing it is either setting > > another cookie (with the auth failure reason) or adding to the URL > query parameters and then reading them > > when displaying the login page... > > > > simran. >
Apache::AuthCookie login faliure reason
Hi All, I am having some trouble getting Apache::AuthCookie (version 3 which i believe is the latest version) to do what want: What i want is: * To be able to give the user a reson if login fails - eg reason: * "No such username" * "Your password was incorrect" Has anyone else come across the same requirement/issue, and how have you solved it? It seems like a difficult one to solve (in a clean way) as the only way i can think of doing it is either setting another cookie (with the auth failure reason) or adding to the URL query parameters and then reading them when displaying the login page... simran.
VirtualHosts-Config inside of modules
Hi, i made a small script to configure an Apache-Webserver via LDAP-entries. First i put everything in a -Section, it worked. Now i want to put it inside a module, and everything works, EXCEPT, that i can't add VirtualHosts. in the -Version i used use vars(%VirtualHost,@NameVirtualHost), but in the module it doens't work, do i need to import something ? do i need a TOTALY different way to access the VirtualHost-Hash ? or is it impossible to change virtualHost/namewirtualhost insode of a module ??? ciao
[OT] Re: Seeking Legal help
At 03:21 PM 11/21/01 -0800, Medi Montaseri wrote: >I did some work (about $25000 worth) for a customer and I'm having >problem collecting. This has been beaten to death on the list, but... (and I'm not a lawyer, but I drink beer with one), If you think they are going Chapter 11, then you may want to try to bargain down to some amount to get something, so you are not on their list of creditors. When they do file, if that's the case, they have to notify the court of their creditors and then the court is suppose to notify you. You must then file a proof of claim, and get in line with everyone else. If you think they might fail to list you as a creditor when they file, contact the court every few weeks and check if they have already filed, and file your proof of claim. Then at least you might get a penny on the dollar... $25K is a bad number, in that it's too big for small claims court, and it's too little to get much help from lawyers in a law suit, I'd guess. Ask them if they want to pay partially in hardware and you might get a good idea of their direction ;). Good luck, Bill Moseley mailto:[EMAIL PROTECTED]
Re: [OT] Re: Seeking Legal help
At 01:34 AM 11/23/2001, Mark Maunder wrote: >Matt Sergeant wrote: > > > Step three: Once you've given them 90 days after date of invoice, get a > > solicitor (not a barrister) to draft a threatening letter. It'll cost you > > about $100. I'm afraid you'll have to give them another 30 days at this > > point. > > > > Step four: Get a lawyer. Sue. $25,000 is not to be sniffed at. > >What many small companies and one man operations dont realise is that debt >collecting is an art. Also, some large companies (large banks in particular) >have a policy of 'If you want to do business with us, we take 60 days to pay. >It's all about keeping the cashflow on their side. It depends on the company, I think most take a long time to pay the first time because it's the first time you are being entered into their computer systems, contracts get signed off completely etc.. Of the large companies (banks included) we work with this is normally the case (a 60-100 day to get paid the first time), but subsequent times are usually quite easy for us as most of our large customers repeat back to us and we are already in their system for getting paid by their accounts payable department. Of course, there are exceptions to the rules, but I don't see large companies just arbitrarily trying to pull a longer cycle. At the least, they do usually have to wait for the accounts payable cycle and cutting an out of cycle check is a pain in the ass, but that comes sooner than 60 days. I think 60 days etc is reasonable if you are on a 1M-2M contract, but if your contract is a few hundred K over a year, it hardly will make that much of a collective cash flow dent to warrant it being worth their policy. By the way, if you are really working for a bank and cashflow is an issue for you in 60 days you can also ask the bank what business banking services they offer. One popular service with small businesses who have large companies working for them is invoice factoring which allows you to sell your invoice (if your company passes a credit check) to the bank for something like 80% of the face value of the account and then when the bank collects the invoice you get the rest minus interest and commissions. It's unlikely that they would grant the same credit with a 1-man company though. And I think they don't like dealing with service businesses. It's usually more for dealing with suppliers with real inventory where the main thing that can go wrong with an invoice is a pricing dispute over a line item of widgets I suspect. The other thing is that if you do a contract, build in billing cycles. 20-30% up front on a fixed fee contract is not unreasonable. Of course, you may need to commence work anyway before getting it if they are a large company that is having trouble getting you in their system, but that is the risk. But in any case, you can soon usually figure out whether they are going ot be paying your schedule or not. If you are just a normal hours-based contractor, then it's a bit more like getting a salary and so I think it is much harder to argue to be paid up front. >I did some work for a certain Linux distributor in the UK recently and they >took 100 days to pay after much harrasment. If you're small you have to be >tough - put the geek aside and become that vicious old lady that is usually >hired to badger late payers. The same all over the world. ;) Later, Gunther
Re: Persistent HTTP Connections ala Apache::DBI
> Has anyone done such a thing before? No doubt. > Can someone point me to docs or > modules which could help doing this? Perhaps raw sockets might be a consideration. However, Apache is great middleware, so I tend to use it in cases like this. You might want to use a session-based approach between the db-Apache and the app-Apache. The db-Apache would cache the connections to the legacy DB returning sessions the app-Apache which would cache them as well. You'd get the performance of cached DB connections without having to ensure the HTTP connections remain alive across app-Apache queries. When a session times out on the db-Apache tier, just rollback (assuming your DB is transactional) and put it in the free pool for new sessions. > Or is this whole idea maybe just > plain stupid? I don't think so. I assume the DB connection cost is high (on the order of seconds) iwc you need some way to cache connections. > Are there obvious caveats I haven't thought of? Garbage collection is an issue. How do you know when to timeout (rollback) queries on db-Apache? Are the queries "atomic" to app-Apache, i.e. within a single end-user HTTP request or do they span multiple end-user requests? (This latter a good idea, imo.) mfg, Rob
Re: Documentation patch for mod_perl//win32
On Fri, 23 Nov 2001, Stas Bekman wrote: > Don't modify the guide, just throw some random and structured winXX > notes into a new doc,and we just add it to the guide as a new chapter. > Then people start sending patches and polish it, like the rest of the > chapters. The new 2.0 docs generation will have each OS specific notes > in its own chapter. > > so if Alessandro or Randy volunteers (please say so), please ask winXX > users to send you more winXX specific notes/scenarios and you (the > volunteer) will be the official maintainer of the doc and send me the > new doc and then the future patches. For 2.0 you will simply have a > commit access and be able to maintain these by yourself and go wild. > Does this sound good? It does ... I'd be happy to volunteer, or co-volunteer if Alessandro or anybody else wants, to do that for Win32. As well as these notes on limitations of the current mod_perl on Win32, there's also some basic installation/use things that have come up in the past that could also go in. best regards, randy
Re: [OT] Re: Seeking Legal help
Matt Sergeant wrote: > Step three: Once you've given them 90 days after date of invoice, get a > solicitor (not a barrister) to draft a threatening letter. It'll cost you > about $100. I'm afraid you'll have to give them another 30 days at this > point. > > Step four: Get a lawyer. Sue. $25,000 is not to be sniffed at. What many small companies and one man operations dont realise is that debt collecting is an art. Also, some large companies (large banks in particular) have a policy of 'If you want to do business with us, we take 60 days to pay. It's all about keeping the cashflow on their side. I did some work for a certain Linux distributor in the UK recently and they took 100 days to pay after much harrasment. If you're small you have to be tough - put the geek aside and become that vicious old lady that is usually hired to badger late payers. Since you're also UK based, a good line you might want to try is "I've already paid the VAT on this invoice. I'd like to know is whether I should write you off as a bad debt so I can claim the VAT back." - assuming you're VAT registered that is. ~mark
Re: [OT] Re: Seeking Legal help
On Thu, 22 Nov 2001, Rodent of Unusual Size wrote: > Um, no, it's spelt "waylaid". :-) As you and everybody else has pointed out (mostly in private email). I was so eager and excited to give Matt some shit that I somehow incorporated part of his mistake. Oh well, that's what I get for teasing. -dave /*== www.urth.org We await the New Sun ==*/
Re: Documentation patch for mod_perl//win32
Randy Kobes wrote: > On Wed, 21 Nov 2001, Alessandro Forghieri wrote: > > >>Greetings. >> >>Randy> That's great that you thought this out and put it together; >>Randy> a few comments below appear below ... >> >>Thanks for playing editor - and I am accepting all of your suggestions, >>with the possible exception of what follows. >> >>Randy> I got confused about which is the "first" and which is the >>Randy> "second" category ... However, is this much detail needed? >> >>The reason this section got in there is that a previous version >>of the guide included a highly opinionated quote against multithreading on >>single processor >>machines, which totally failed to take into account applications with long >>running requests (except for saying that such apps should not exist). Hence >>the counter-example, which I have now somewhat shortened. >>If there is still a consensus on it being overkill, >>I can drop it altogether. >> > > I wasn't aware of that ... perhaps the section of the guide you > refer to could be revised? Anyway, in that context, I think > having this section in isn't overkill, and would be good to leave > in. The revisions look good - balanced, yet detailed enough that > people reading it shouldn't get surprised by this behaviour. Don't modify the guide, just throw some random and structured winXX notes into a new doc,and we just add it to the guide as a new chapter. Then people start sending patches and polish it, like the rest of the chapters. The new 2.0 docs generation will have each OS specific notes in its own chapter. so if Alessandro or Randy volunteers (please say so), please ask winXX users to send you more winXX specific notes/scenarios and you (the volunteer) will be the official maintainer of the doc and send me the new doc and then the future patches. For 2.0 you will simply have a commit access and be able to maintain these by yourself and go wild. Does this sound good? On this note any volunteers to start working on OS specific notes for other OSs? (BSD/Solaris/AIX/HP-UX/Mac). _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [OT] Re: Seeking Legal help
* On 2001-11-22 at 10:37, Dave Rolsky <[EMAIL PROTECTED]> excited the electrons to say: > > On Wed, 21 Nov 2001, Matt Sergeant wrote: > > > Maybe they weighlayed your invoice. Or don't have the money just yet but > ^^^??? > > You folks may have invented the language but its still spelled waylayed! Um, no, it's spelt "waylaid". :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
RE: Apache::Session Problem -- Addendum
At 10:43 AM + 11/22/01, Jonathan M. Hollin wrote: >Thank you everyone for the quality of help I've so far received and your >rapid responses. However... :-( At the rist of making a shameless plug, you can visit http://www.kitebird.com/mysql-perl/ and grab the webdb source distribution there. This accompanies the book for which the aforementioned URL is the home site. Said book has a chapter on sessions focusing on Apache::Session, so you may find the example scripts useful for helping you solve your problem. > >My code now includes: > >35: # Session handler... >36: my %session; undef my $session_id; >37: use Apache::Session::MySQL; >38: tie %session, 'Apache::Session::MySQL', $session_id, >39: { DataSource => 'dbi:mysql:sessions', UserName => 'db_user', Password >=> 'secret' }; >40: $session_id = "session_id=$session{_session_id};"; > >I am using Apache-Session v1.54. > >The above code generates the following error: > >[Thu Nov 22 10:31:38 2001] [error] PerlRun: `Can't connect( >HASH(0xbdcf54)), no database driver specified and DBI_DSN env var not set at >E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36 (in cleanup) >Can't connect( HASH(0x47e2f14)), no database driver specified and DBI_DSN >env var not set at E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36' > >So, as you can see, I've moved on a little - but still don't have a working >session handler. Any offers? > >Note: I know how boring it is to keep reading the same thread - I'll drop >it if I don't solve this today. > >Kindest regards, > >Jonathan M. Hollin - WYPUG Co-ordinator >West Yorkshire Perl User Group >http://wypug.pm.org/ > >:: -Original Message- >:: From: Tatsuhiko Miyagawa [mailto:[EMAIL PROTECTED]] >:: Sent: 22 November 2001 04:34 >:: To: [EMAIL PROTECTED] >:: Cc: mod_perl Mailing List >:: Subject: Re: Apache::Session Problem -- Addendum >:: >:: >:: On Wed, 21 Nov 2001 23:23:33 - >:: "Jonathan M. Hollin" <[EMAIL PROTECTED]> wrote: >:: >:: > 42: tie %session, 'Apache::Session::DBI', >:: > 43: {DataSource => "dbi:$db_driver:sessions:$db_address"}; >:: >:: put $sid (session id: undef for fresh) after 'Apache::Session::MySQL'. >:: >:: -- >:: Tatsuhiko Miyagawa <[EMAIL PROTECTED]> >::
Re: Documentation patch for mod_perl//win32
On Wed, 21 Nov 2001, Alessandro Forghieri wrote: > Greetings. > > Randy> That's great that you thought this out and put it together; > Randy> a few comments below appear below ... > > Thanks for playing editor - and I am accepting all of your suggestions, > with the possible exception of what follows. > > Randy> I got confused about which is the "first" and which is the > Randy> "second" category ... However, is this much detail needed? > > The reason this section got in there is that a previous version > of the guide included a highly opinionated quote against multithreading on > single processor > machines, which totally failed to take into account applications with long > running requests (except for saying that such apps should not exist). Hence > the counter-example, which I have now somewhat shortened. > If there is still a consensus on it being overkill, > I can drop it altogether. I wasn't aware of that ... perhaps the section of the guide you refer to could be revised? Anyway, in that context, I think having this section in isn't overkill, and would be good to leave in. The revisions look good - balanced, yet detailed enough that people reading it shouldn't get surprised by this behaviour. best regards, randy
Re: sections from within a module
Issac Goldstand wrote: > Is there a way of doing configuration work (the equivalent of > sections) from within modules? I ask both for subroutines which are > called at server startup (from mod_perl_start.pl) and from other handlers... Yup, just modify things in Apache::ReadConfig package. The only magical thing about is that it declares: package Apache::ReadConfig; for you... it's explained here: http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl (and I think the eagle book): _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
sections from within a module
Is there a way of doing configuration work (the equivalent of sections) from within modules? I ask both for subroutines which are called at server startup (from mod_perl_start.pl) and from other handlers... Thanks in advance, Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Persistent HTTP Connections ala Apache::DBI
I'm working on a web application which obtains data via a legacy system rather than DBI. Using DBI is (unfortunately) not an option. The machine where the web application runs cannot run the legacy system. Thus, the setup looks somewhat like this: DB <=> DB Query (Legacy) <=> Apache/mod_perl <=> Client I was thinking to make the connection between DB Query and Apache/mod_perl using HTTP, so there will be an Apache running on the DB Query tier for access to the legacy system. What I'm interested in, is a persistent HTTP connection between the Apache/mod_perl tier and the DB Query tier. I'm thinking of a ChildInit handler which opens up a HTTP/1.1 connection to the apache sitting on the DB query tier. The connection would use keep-alive, which of course would be enabled and set to high timeout values on the DB Legacy tier. This is more or less what Apache::DBI does, just in this case it should be something like Apache::PersistentHTTPConnection. Unfortunately, I haven't found such a thing. Has anyone done such a thing before? Can someone point me to docs or modules which could help doing this? Or is this whole idea maybe just plain stupid? Are there obvious caveats I haven't thought of? Any comments are welcome.
RE: Apache::Session Problem -- Addendum
Thank you everyone for the quality of help I've so far received and your rapid responses. However... :-( My code now includes: 35: # Session handler... 36: my %session; undef my $session_id; 37: use Apache::Session::MySQL; 38: tie %session, 'Apache::Session::MySQL', $session_id, 39: { DataSource => 'dbi:mysql:sessions', UserName => 'db_user', Password => 'secret' }; 40: $session_id = "session_id=$session{_session_id};"; I am using Apache-Session v1.54. The above code generates the following error: [Thu Nov 22 10:31:38 2001] [error] PerlRun: `Can't connect( HASH(0xbdcf54)), no database driver specified and DBI_DSN env var not set at E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36 (in cleanup) Can't connect( HASH(0x47e2f14)), no database driver specified and DBI_DSN env var not set at E:/Apache/site/lib/Apache/Session/Lock/MySQL.pm line 36' So, as you can see, I've moved on a little - but still don't have a working session handler. Any offers? Note: I know how boring it is to keep reading the same thread - I'll drop it if I don't solve this today. Kindest regards, Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ :: -Original Message- :: From: Tatsuhiko Miyagawa [mailto:[EMAIL PROTECTED]] :: Sent: 22 November 2001 04:34 :: To: [EMAIL PROTECTED] :: Cc: mod_perl Mailing List :: Subject: Re: Apache::Session Problem -- Addendum :: :: :: On Wed, 21 Nov 2001 23:23:33 - :: "Jonathan M. Hollin" <[EMAIL PROTECTED]> wrote: :: :: > 42: tie %session, 'Apache::Session::DBI', :: > 43: {DataSource => "dbi:$db_driver:sessions:$db_address"}; :: :: put $sid (session id: undef for fresh) after 'Apache::Session::MySQL'. :: :: -- :: Tatsuhiko Miyagawa <[EMAIL PROTECTED]> ::
usage of die() inside a mod_perl Apache handler shows not the expected behavior
Hi, I use the following configuration: PerlHandlerApache::MyPkg SetHandler perl-script and the handler is defined in this way: package Apache::MyPkg require 5.005; require Apache::Request; use constant TmpDir => '/var/tmp'; use strict; sub handler ($) { my $apr = Apache::Request->instance(shift, TEMP_DIR => TmpDir); ... } But the first which I have not expected is that $^S is always true inside this handler. The other problem is that die "text which does not end in a newline" shows text which does not end in a newline during global destruction.\n instead the expected text which does not end in a newline at __FILE__ line __LINE__.\n Is this a bug in mod_perl? I use mod_perl 1.25 and Perl 5.00503. 5.6 is no choice, because there is a known incompatibility of mod_perl, Perl 5.6 and the platform I must use. My current work around is: require Error; ... sub handler ($) { my $apr = Apache::Request->instance(shift, TEMP_DIR => TmpDir); local $SIG{__DIE__} = sub { my $txt = join '', @_; local $Error::Depth = $Error::Depth + 1; $txt =~ s/\s+during\s+global\s+destruction.\s*\z//; die(Error::Simple->new($txt)->stringify); }; ... } TIA, Silvio
Re: Seeking Legal help
From experience in the dotcom world I can tell you this, its a hard balance to fight. The more you push and threaten the lower on the pile of bills you will go. If this company is going to file for Chapter 11 they have no incentive to pay you at all. In fact, I remember watching management purposefully pushing the more aggressive debtors to the bottom of the list knowing full well they would never get paid. Best strategy from my perspective is to offer them a better deal. Take say $15k and write it off to a bad debt. They are much more likely to respond to a nice guy offer of 'I know things are tough, lets make a deal' then 'I will get my lawyer to yell at you at which point you will ignore me until you go out of business'. Debt collection is nasty when the players are not solvent. John- On Wednesday, November 21, 2001, at 03:21 PM, Robert Landrum wrote: >> > > Contact a lawyer. Then tell the client that you have contacted a > lawyer. Put this in writing and sign it. Be specific and let them > know what it is exactly that you want, and that if they do not comply, > you'll be forced to enlist the service of a lawyer and file suit. > > Most of the time, this will be enough to get them to pay... Nobody > want's a legal battle, least of all a small business. > > If they fail to pay, you have two options. Bite the bullet and move on > or sue them. > > I am not a lawyer, but this is the process that my friend went through > when he did about $20,000 worth of work for a client that was more than > 180 days delinquent. After court costs and lawyer fees, etc., he > walked away with > $8,000. > > Not great, but better than nothing. > > Rob > > > -- > "Only two things are infinite: The universe, and human stupidity. And > I'm not > sure about the former." --Albert Einstein