RE: [Catalyst] Invalid session ids being generated
I forgot to include the error in the log: FastCGI: server "/u/lxlib/BookingEngine/script/bookingengine_fastcgi.pl" stderr: [error] Caught exception in engine "DBIx::Class::Relationship::CascadeActions::update(): Can't update BookingEngine::Model::DBIC::BE::Session=HASH(0xd3f2620): row not found at /usr/lib/perl5/site_perl/5.8.5/Catalyst/Plugin/Session/Store/DBIC/Delega te.pm line 85" Ryan Pack Programmer Genares Worldwide Reservations P. 817-722-2834 F. 817-442-0600 From: Ryan Pack [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 5:38 PM To: catalyst@lists.scsys.co.uk Subject: [Catalyst] Invalid session ids being generated My Catalyst app is using Session::State::Cookie, Session::State::URI, and Session::Store::DBIC. We recently started using the param option in Session::State::URI. We were tacking the session id onto the base URL but now it is being included as a parameter. Anyways, when you first make a request, a cookie is set with a valid session_id but uri_for returns the url with a totally different session id which doesn't even exist in the database. We are including the uri_for generated url for form actions and links, etc. in our templates in case cookies are disabled. Has anyone seen this before? Ryan Pack Programmer Genares Worldwide Reservations P. 817-722-2834 F. 817-442-0600 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Invalid session ids being generated
My Catalyst app is using Session::State::Cookie, Session::State::URI, and Session::Store::DBIC. We recently started using the param option in Session::State::URI. We were tacking the session id onto the base URL but now it is being included as a parameter. Anyways, when you first make a request, a cookie is set with a valid session_id but uri_for returns the url with a totally different session id which doesn't even exist in the database. We are including the uri_for generated url for form actions and links, etc. in our templates in case cookies are disabled. Has anyone seen this before? Ryan Pack Programmer Genares Worldwide Reservations P. 817-722-2834 F. 817-442-0600 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] FastCGI: incomplete headers (0 bytes) received fromserver
Thanks everyone for your replies. Turns out that this error had nothing to do with the problem I am trying to track down. I will post a new thread with a more appropriate subject line. Ryan Pack Programmer Genares Worldwide Reservations P. 817-722-2834 F. 817-442-0600 From: Martin Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 1:03 AM To: The elegant MVC web framework Subject: Re: [Catalyst] FastCGI: incomplete headers (0 bytes) received fromserver The error is presumably because your fast cgi system has a timeout. Do you have some code that sometimes takes a long time to run? If it only happens about 1% of the time it may be normally just quicker than the limit, but occasionally going over. 2008/5/7 John Goulah <[EMAIL PROTECTED]>: On Tue, May 6, 2008 at 1:01 PM, Ryan Pack <[EMAIL PROTECTED]> wrote: > > > > > I'm having an issue with my Catalyst app but I can only get it to break > about 1 in 100 tries. The error log shows: > > > > [Tue May 06 11:02:46 2008] [error] [client 12.37.36.66] FastCGI: comm with > server "/u/lxlib/BookingEngine/script/bookingengine_fastcgi.pl" aborted: > idle timeout (60 sec), referer: http://be.genares.net/11 > > [Tue May 06 11:02:46 2008] [error] [client 12.37.36.66] FastCGI: incomplete > headers (0 bytes) received from server > "/u/lxlib/BookingEngine/script/bookingengine_fastcgi.pl", referer: > http://be.genares.net/11 > > > For what its worth, I also get the latter error quite a bit in my error logs. Haven't really had time to trace it down, looks similar something like: [Tue May 06 10:09:34 2008] [error] [client 204.2.215.55] FastCGI: incomplete headers (0 bytes) received from server "/opt/myapp.com/app/MyApp/1.007556/fake/www" I think the only thing in common here is Session::State::Cookie; we use Session::Store::Cache. Probably doesn't help much but I guess the problem does exist for various reasons if anyone has any ideas I'd be glad to try, but "adding some debug messages in key places" isn't going to cut it. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst / dbix-class / mysql / REST job
There were a few long threads on the subject of REST CRUD in Catalyst here. Maybe you would like to crowd source a bit - and make a competition for the code pieced that you need? Inspiration: http://www.ddj.com/architect/207404123?pgno=1 Cheers, Zbigniew On Wed, May 7, 2008 at 6:52 PM, Mark Trostler <[EMAIL PROTECTED]> wrote: > The job description is kinda crapy: > > http://jobs.perl.org/job/8624 > > But you can work in Sunnyvale, CA or Carslbad, CA. > > The backend in Catalyst/REST/DBIx::Class/MySQL. > > Frontends are currently command line/library using Moose and lots of AJAXy > Javascript (using ExtJS - yah should be YUI ideally...). > > Join the team! > Mark > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Anybody who fancies some LWP poking ...
Not sure who that's pointed at Matt, but if you mean me, sorry for that. In all honesty, if I could've worked out *what* needed fixing and where, I would have done so. What I did was at least try to indicate to people where the error was coming from and why, and what they might do temporarily in order to get a workaround. In the absence of any actual understanding of *why* the changes which triggered the problem were made, trying to actually implement a fix didn't seem a very good idea. At any rate, the suggestion of some kind of stable/testing rating for module releases sounds like a pretty good idea. > > Not when you're that far down the dependency chain. > > Anyway, this thread was started to try and help get the fallout fixed, > not for you to posture. Either write code, shut up, or start a separate > thread so I can safely killfile it. > ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst / dbix-class / mysql / REST job
Mark Trostler wrote: The job description is kinda crapy: http://jobs.perl.org/job/8624 But you can work in Sunnyvale, CA or Carslbad, CA. The backend in Catalyst/REST/DBIx::Class/MySQL. Frontends are currently command line/library using Moose and lots of AJAXy Javascript (using ExtJS - yah should be YUI ideally...). Join the team! Mark Sure it's not a Catalyst/RPC/DBIx::Class/MySQL instead? :-) signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Catalyst / dbix-class / mysql / REST job
The job description is kinda crapy: http://jobs.perl.org/job/8624 But you can work in Sunnyvale, CA or Carslbad, CA. The backend in Catalyst/REST/DBIx::Class/MySQL. Frontends are currently command line/library using Moose and lots of AJAXy Javascript (using ExtJS - yah should be YUI ideally...). Join the team! Mark ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Dispatching with Chained vs HTTP method
On Wed, May 07, 2008 at 08:38:18AM -0400, Garrett Goebel wrote: > > Also important is how to allow people to limit which sets of tuples and > relationships are publically accessible. For production work the default > should probably require the REST interfaces to be explicitly published. > Otherwise, with any set of tables with more than a handful of records, > it will be fairly simple to bring the database to its knees with a URL > that performs multiple joins on a large set of records. As a compromise, > you might allow primary key candidates (keys which match exactly one > record) and "have one" relationships to be public by default, but not > "have many" or "many to many" relationships. or ask the database how long the query will take and then limit on that? Regards, Paddy ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Dispatching with Chained vs HTTP method
Zbigniew Lukasiak wrote: On Wed, May 7, 2008 at 7:57 AM, Toby Corkindale <[EMAIL PROTECTED]> wrote: $id = POST transaction $amount = GET /user/1/account_balance $amount2 = GET /user/2/account_balance PUT /user/1/account_balance/$amount-1 PUT /user/2/account_balance/$amount+1 PUT transaction/$id?completed How about: $id = POST transaction PUT /transaction/$id/payer/1 PUT /transaction/$id/receiver/2 PUT /transaction/$id/amount/1 PUT /transaction/$id?completed or even $id = POST transaction PUT /transaction/$id?payer=1;receiver=2;amount=1 PUT /transaction/$id?completed A couple years back when I hacked together REST(like) CRUD with Catalyst... I opted for the latter. As it seemed at the time to be a better way to represent the possible keys to tuples. I haven't been able to pay much attention to this thread. Not enough tuits. Sorry if I'm going over ground which has already been covered... But I hope the people who are implementing it spend some time thinking about making the interface introspective. Also important is how to allow people to limit which sets of tuples and relationships are publically accessible. For production work the default should probably require the REST interfaces to be explicitly published. Otherwise, with any set of tables with more than a handful of records, it will be fairly simple to bring the database to its knees with a URL that performs multiple joins on a large set of records. As a compromise, you might allow primary key candidates (keys which match exactly one record) and "have one" relationships to be public by default, but not "have many" or "many to many" relationships. I think thinking in terms of using the underlying databases' transactions across multiple GET | PUT | POST | DELETE's is a mistake. For the reasons others have already pointed out. Except where you collect the data for your complex set of interrelated tuples and commit it in one go. Which of course means you need to be able to catch and handle the conflicts which can occur between starting to create your set of tuples and finally committing it. cheers and good luck... Garrett ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Strange UTF16 warning
Sorry, my mailer did not quote the original post from Tue, 30 Oct 2007 17:10:07 -0800 I'm seeing warnings of the type "UTF-16 surrogate 0xABCD" in my logs that I'm not quite sure how to explain. I am familiar with the nature of the warning message, and I've tracked it to Catalyst::Engine->write -- but I'm not sure exactly what's triggering it. The response body does contain the character sequences in question, but the Content-Type is application/octet-stream (that's JPEG to you AOL folks) and the UTF flag is off for the string. There doesn't seem to be any corruption of the output, the JPEGs work. But I'm concerned that something is treating my output as UTF8 or otherwise "stringy" when it shouldn't be. Any ideas? Thanks in advance, Brian Kirkbride 2008/5/7 Martin Ellison <[EMAIL PROTECTED]>: > I've got the same problem for the same reason (trying to return a JPEG). > Presumably something thinks that it is getting text (Unicode) and picks up > some special characters. Is there some equivalent of binmode for body? > -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Strange UTF16 warning
I've got the same problem for the same reason (trying to return a JPEG). Presumably something thinks that it is getting text (Unicode) and picks up some special characters. Is there some equivalent of binmode for body? -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Dispatching with Chained vs HTTP method
On Wed, May 07, 2008 at 06:02:46PM +1000, Adam Clarke wrote: > On 07/05/2008, at 3:57 PM, Toby Corkindale wrote: >> On Wed, May 07, 2008 at 03:30:12PM +1000, Adam Clarke wrote: >>> >>> The solution suggested in "Restful Web Services" is to POST to a >>> "factory" >>> resource which creates you with a transaction resource. e.g. "POST >>> /transactions/account-transfer" returns "Location: >>> /transactions/account-transfer/11a5", where the 11a5 is a unique >>> transaction identifier. >>> >>> Then "PUT /transactions/account-transfer/11a5/accounts/checking/11", >>> where >>> 11 is the account identifier. The body carries the transaction details, >>> in >>> the example the balances are adjusted absolutely, i.e. "balance=150". A >>> similar PUT is sent for the other account. >>> >>> Once the required components of the transaction have been PUT it is >>> possible to rollback by DELETEing the transaction resource or commit it >>> by >>> putting "committed=true" to the resource. >>> >>> While seeming a bit fiddly, it does keep the state on the client and >>> allows >>> the client to make (at least some of) the commit / rollback decision >>> rather >>> than (only) the server. >> >> I've read parts of RESTful Web Services, but not that bit.. I'll have to go >> back and look. >> >> I wonder how one goes about implementing such a transaction on the server >> side.. One would not want to lock DB rows indefinitely, waiting for the >> client to finally complete the transaction. But if one just recorded the >> queries and then executed them all (internally) at the end, then other risks >> exist, eg: > > I haven't done this before, but I have thought about it a bit. I think I > would handle this as a two-phase commit. PostgreSQL has "PREPARE > TRANSACTION" which allows you to start a transaction and assign it a > "transaction_id" for use with a subsequent "COMMIT TRANSACTION". I would > also use Multi-Version Concurrency Control (MVCC) rather than any kind of > blocking locks to minimise the impact of the longer transaction lifetime. I'm not sure the former command does what we'd like it to - after running it, I don't think you can add any further commands to it; it's merely held in stasis until you commit/rollback it, and you can start another transaction meanwhile. I *think* but I haven't used it either. Regarding the MVCC; that's a rather good idea, although my understanding of postgres is that it will start blocking in conditions where you're updating the same thing. (Edit: Just tested - it seems to) That said, I don't know how other systems handle it, or if in fact the SET SERIALISATION parameter to psql can alter this behaviour.. Are there other MVCC implementations which manage it? You seem to have a good idea about using that rather than locking. Something else occured to me - Have you had any experience at trying to get DB transactions to span connections? Since the HTTP requests could hit different processes for each request (or possibly even different servers in a farm).. I suppose one could push the DB requests to a back-end processing daemon that could ensure a consistent connection was used, but again seems to be tieing up resources if there's a network drop-out. I haven't looked into that at all really though. I was just assuming one might have to use locks as they would span, but that would be ugly, and breaks the concept of not storing state on the server for REST. > This would at least keep a good deal of the hard work in the DB. *nods* I agree that's the best option. I'm mainly familiar with Postgres (and a little of MySQL) so I don't know if the commercial DBs have added features to help with these issues already? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Dispatching with Chained vs HTTP method
On Wed, May 07, 2008 at 09:55:10AM +0200, Zbigniew Lukasiak wrote: > On Wed, May 7, 2008 at 7:57 AM, Toby Corkindale <[EMAIL PROTECTED]> wrote: [snip] > > I wonder how one goes about implementing such a transaction on the server > > side.. One would not want to lock DB rows indefinitely, waiting for the > > client to finally complete the transaction. But if one just recorded the > > queries and then executed them all (internally) at the end, then other > > risks exist, eg: > > > > $id = POST transaction > > $amount = GET /user/1/account_balance > > $amount2 = GET /user/2/account_balance > > PUT /user/1/account_balance/$amount-1 > > PUT /user/2/account_balance/$amount+1 > > PUT transaction/$id?completed > > How about: > > $id = POST transaction > PUT /transaction/$id/payer/1 > PUT /transaction/$id/receiver/2 > PUT /transaction/$id/amount/1 > PUT /transaction/$id?completed > > or even > > $id = POST transaction > PUT /transaction/$id?payer=1;receiver=2;amount=1 > PUT /transaction/$id?completed There are other ways of doing it that would avoid the problem, but I'm just trying to demonstrate potential flaws in any transaction that does not do locking to prevent other things accessing it at the same time. Perhaps I should try another example if the other wasn't clear. Given this series of calls: 1) get value of item 2) get users bank balance if balance > item-value, then: 3) subtract value from bank balance 4) assign item to user What if the internet connection died for 30 seconds between step (2) and (4), and in that 30 seconds, the user bought something elsewhere, thus reducing his or her balance to below the value? That's the sort of race condition that real databases can avoid, because they'll basically stop anyone else modifying the balance after you've checked it, until you commit or rollback the transaction. We could do that too.. But imagine if we locked the user's DB row at step (2).. but then imagine if the internet connection to the person who started the transaction died.. for hours.. and during that time no other transactions could be made! That's not so good either. Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Dispatching with Chained vs HTTP method
On 07/05/2008, at 3:57 PM, Toby Corkindale wrote: On Wed, May 07, 2008 at 03:30:12PM +1000, Adam Clarke wrote: The solution suggested in "Restful Web Services" is to POST to a "factory" resource which creates you with a transaction resource. e.g. "POST /transactions/account-transfer" returns "Location: /transactions/account-transfer/11a5", where the 11a5 is a unique transaction identifier. Then "PUT /transactions/account-transfer/11a5/accounts/checking/ 11", where 11 is the account identifier. The body carries the transaction details, in the example the balances are adjusted absolutely, i.e. "balance=150". A similar PUT is sent for the other account. Once the required components of the transaction have been PUT it is possible to rollback by DELETEing the transaction resource or commit it by putting "committed=true" to the resource. While seeming a bit fiddly, it does keep the state on the client and allows the client to make (at least some of) the commit / rollback decision rather than (only) the server. I've read parts of RESTful Web Services, but not that bit.. I'll have to go back and look. I wonder how one goes about implementing such a transaction on the server side.. One would not want to lock DB rows indefinitely, waiting for the client to finally complete the transaction. But if one just recorded the queries and then executed them all (internally) at the end, then other risks exist, eg: I haven't done this before, but I have thought about it a bit. I think I would handle this as a two-phase commit. PostgreSQL has "PREPARE TRANSACTION" which allows you to start a transaction and assign it a "transaction_id" for use with a subsequent "COMMIT TRANSACTION". I would also use Multi-Version Concurrency Control (MVCC) rather than any kind of blocking locks to minimise the impact of the longer transaction lifetime. This would at least keep a good deal of the hard work in the DB. Cheers -- Adam ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Dispatching with Chained vs HTTP method
On Wed, May 7, 2008 at 7:57 AM, Toby Corkindale <[EMAIL PROTECTED]> wrote: > Hi Adam, > > > > On Wed, May 07, 2008 at 03:30:12PM +1000, Adam Clarke wrote: > > On 07/05/2008, at 11:05 AM, Toby Corkindale wrote: > > > >> Ah, I was thinking of transactions vs a REST API, eg: > >>PUT /user/1234/account_balance?subtract=1 > >>POST /user/4567/account_balance?add=1 > >> Since those are two separate HTTP requests, and REST specifically states > >> you > >> cannot maintain state on the server, how would you perform those two > >> operations inside a transaction? > >> > >> (My "solution" is to implement it in one request, like: > >>PUT /user/1234/money_transfer?user=4567;amount=1 > >> However that is not CRUD-like, nor a direct mapping of DBIC functionality > >> to > >> REST) > > > > The solution suggested in "Restful Web Services" is to POST to a "factory" > > resource which creates you with a transaction resource. e.g. "POST > > /transactions/account-transfer" returns "Location: > > /transactions/account-transfer/11a5", where the 11a5 is a unique > > transaction identifier. > > > > Then "PUT /transactions/account-transfer/11a5/accounts/checking/11", where > > 11 is the account identifier. The body carries the transaction details, in > > the example the balances are adjusted absolutely, i.e. "balance=150". A > > similar PUT is sent for the other account. > > > > Once the required components of the transaction have been PUT it is > > possible to rollback by DELETEing the transaction resource or commit it by > > putting "committed=true" to the resource. > > > > While seeming a bit fiddly, it does keep the state on the client and allows > > the client to make (at least some of) the commit / rollback decision rather > > than (only) the server. > > I've read parts of RESTful Web Services, but not that bit.. I'll have to go > back and look. > > I wonder how one goes about implementing such a transaction on the server > side.. One would not want to lock DB rows indefinitely, waiting for the > client > to finally complete the transaction. But if one just recorded the queries and > then executed them all (internally) at the end, then other risks exist, eg: > > $id = POST transaction > $amount = GET /user/1/account_balance > $amount2 = GET /user/2/account_balance > PUT /user/1/account_balance/$amount-1 > PUT /user/2/account_balance/$amount+1 > PUT transaction/$id?completed How about: $id = POST transaction PUT /transaction/$id/payer/1 PUT /transaction/$id/receiver/2 PUT /transaction/$id/amount/1 PUT /transaction/$id?completed or even $id = POST transaction PUT /transaction/$id?payer=1;receiver=2;amount=1 PUT /transaction/$id?completed And - yeah - looks like we have differnet goals. But I'll watch your project proceeding :) -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Wikipedia article improvement?
The Wikipedia article on Catalyst ( http://en.wikipedia.org/wiki/Catalyst_%28software%29) could do with some improvement and updating. -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/