Nov 16 18:59:10 <Remi>	Hello everyone  :-)
Nov 16 18:59:30 <slate>	hello
Nov 16 18:59:38 <Lawouach_>	hi
Nov 16 19:00:47 <martin>	hey
Nov 16 19:01:19 <Remi>	I'm going to start adding some recipes to the Wiki (documentation is the most wwanted feature about CP2...)
Nov 16 19:02:42 <martin>	agree, although i think the examples go a long way if you a little bit of CP1
Nov 16 19:03:02 >NickServ<	identify ****
Nov 16 19:03:02 ---	Lawouach_ sets mode +R Lawouach_
Nov 16 19:03:02 -NickServ-	Password accepted - you are now recognized.
Nov 16 19:04:20 <Remi>	yeah, but people have to translate them to CP2, which is not trivial if you don't know how CP2 work ...
Nov 16 19:04:55 <Remi>	and I'm also trying to have dinner at the same time ;-)
Nov 16 19:05:26 <martin>	sorry I meant the CP2 examples go a long way, an yeah multitaking here also
Nov 16 19:05:35 <martin>	multitasking
Nov 16 19:07:47 <martin>	how is the orderly server stopping feature comming ? 
Nov 16 19:08:24 <Remi>	"orderly server" ??
Nov 16 19:09:14 <Remi>	what's that ?
Nov 16 19:09:58 <martin>	aren't you working on creating a way to halt the server without ctrl-c or ctrl-break ? orderly as in proper
Nov 16 19:10:46 <Remi>	Oh, I see ...
Nov 16 19:10:54 <Remi>	Well, it's not a high priority right now ...
Nov 16 19:11:27 <Remi>	And it's related to the "control center" problem (being able to reload a CP app without stopping the server), which is a difficult problem ...
Nov 16 19:11:55 <martin>	ok, I guess it shouldn't be, after all ctrl-c or killing the process works.....
Nov 16 19:12:51 <Remi>	The problem is when you have a poolof threads ...
Nov 16 19:13:19 <Remi>	There is no portable way to kill all the threads from another thread (os._exit doesn't work ...)
Nov 16 19:14:23 <Remi>	The unittest uses a hack: when a thread receives the order to shutdown the server (special request), it sets the thread names to a special name
Nov 16 19:14:40 <Remi>	and when the other threads see that their names has changes, they shut themselves down ...
Nov 16 19:14:47 <Remi>	It works but it's pretty hacky ...
Nov 16 19:15:03 <martin>	I thought i saw a module that implements cross thread communication..but I don't know if it supports actually stopping other threads...ill look
Nov 16 19:16:06 <Remi>	that could be an option ... but at the same time, I'm trying to limit the dependencies that CP has (it has none right now).
Nov 16 19:16:20 <Remi>	But maybe we could just include  the code from that module in CP itself ...
Nov 16 19:19:10 <martin>	I a trying to find the module
Nov 16 19:22:29 <Lawouach_>	<Remi> but at the same time, I'm trying to limit the dependencies that CP has (it has none right now). <-- good point
Nov 16 19:25:18 <Lawouach_>	Remi, it would be nice that you provide a short list of things that really needs to be done to move forward in the next month
Nov 16 19:25:32 <Lawouach_>	because even with Tracsi'm still lost on what needs to be done
Nov 16 19:26:20 <martin>	The module is called Microthreads -> http://willware.net:8080/uthread.html
Nov 16 19:27:28 <Remi>	Lawouach: Well, there isn't much that need to be done codewise for a 2.0.0 release.
Nov 16 19:27:55 <Remi>	Just finalize the uri->object mapping algorithm (I'm still waiting for Carlos on this)
Nov 16 19:28:26 <Remi>	and that's pretty much it.
Nov 16 19:28:32 <Remi>	But the main thing is documentation ...
Nov 16 19:28:54 <Remi>	I'll write a few recipes (to set a style) and then I'd like people to add dozens of them :-)
Nov 16 19:30:27 <Lawouach_>	ok
Nov 16 19:30:37 <Lawouach_>	I was reviewing the code the other day
Nov 16 19:30:45 <Lawouach_>	and something annoyed me
Nov 16 19:30:56 <Remi>	martin: uthread uses Stackless :-(
Nov 16 19:30:58 <Lawouach_>	the length of the method handleRequest is really big
Nov 16 19:31:18 <martin>	Yeah I just saw that - bummer
Nov 16 19:31:20 <Lawouach_>	It would be nice to split it in sub routines to keep it clear
Nov 16 19:31:32 <Remi>	Lawouach: sure, that should be easy
Nov 16 19:31:48 <Lawouach_>	besides, what annoys me as well is that we do a lot of checking to see if the request is XML-RPC and most of the time it won't be
Nov 16 19:32:07 <Lawouach_>	the overhead is not great
Nov 16 19:32:16 <Lawouach_>	but it is a bit confusing code-wise
Nov 16 19:32:34 <Remi>	True: maybe we should just check that in one place and then branch off to a different function if it is
Nov 16 19:32:59 <Lawouach_>	yeap
Nov 16 19:33:29 <martin>	I know looks has nothing to do with how CP2 works, but it is *really* important for adoption. I think one good looking example would do wonders. Unfortunatly I am no designer.
Nov 16 19:34:01 <martin>	Also remi as you have said yourself the name could use some tuning
Nov 16 19:34:19 <Lawouach_>	martin, ?
Nov 16 19:34:21 <Remi>	ah, the infamous name debate ;-)
Nov 16 19:35:31 <Lawouach_>	eh eh
Nov 16 19:35:38 <Lawouach_>	CherryPy sounds nice to me
Nov 16 19:36:09 <martin>	What I am saying is that I think it would be a good idea to create a useable but fairly simple web app, like and address book or somthing that looks good...somthing a la MovableType or flickr
Nov 16 19:36:12 <Lawouach_>	Remi, what filters should we add to the basic ones ?
Nov 16 19:36:42 <Lawouach_>	a blog using cherrypy would be enough IMO
Nov 16 19:36:53 <Lawouach_>	a blog based on CP2 I mean
Nov 16 19:37:30 <martin>	a blog would be fine I guess, but there is currently massive competition in that field...a lot of noise to break through
Nov 16 19:42:18 <martin>	has anybody heard about ruby on rails....my feeling is that it ows a lot of the hype to Basecamp - which looks superb - being out there
Nov 16 19:44:05 <Remi>	sorry, was on the phone ...
Nov 16 19:44:25 <Lawouach_>	Remi, come on, stop ordering pizzas !
Nov 16 19:44:30 <Remi>	LOL ...
Nov 16 19:44:48 <Remi>	yeah, I've heard of Rails ...
Nov 16 19:45:10 <Remi>	I think the hype is also due to the fact that Ruby advocates pop up in every forum :-)
Nov 16 19:45:32 <Lawouach_>	martin, a link ?
Nov 16 19:45:46 <Remi>	And yes, it certainly helps to have a great application to demonstrate a framework (just like Plone helped Zope a lot)
Nov 16 19:45:50 <Remi>	rubyonrails.org
Nov 16 19:46:50 <martin>	I know Mr. Bicking's point of view and I agree with it - it is not all what it is cranked up to be, BUT it gets attention and usage
Nov 16 19:46:51 <martin>	 exitAll(reallyAll=FALSE)
Nov 16 19:46:59 <martin>	ups !
Nov 16 19:47:07 <martin>	www.rubyonrails.org
Nov 16 19:47:22 <Remi>	yup
Nov 16 19:48:42 <martin>	and it doesn't do anything that CP2, CherryTemplate/Cheetah and SQLObject does not do
Nov 16 19:49:08 *	Lawouach_ doesn't like Ruby for its syntax, but the language is nifty sometimes compare to Python
Nov 16 19:49:10 <Lawouach_>	anyhow
Nov 16 19:51:32 <Lawouach_>	so what kind of documentation would you need to be added Remi ?
Nov 16 19:51:37 <Lawouach_>	how could we help ?
Nov 16 19:51:57 <Remi>	Recipes ...
Nov 16 19:52:02 <Remi>	I'm writing the first one right now ...
Nov 16 19:52:05 <Lawouach_>	k
Nov 16 19:52:17 <Lawouach_>	boring I guess... :)
Nov 16 19:52:32 -->	cribeiro (~cribeiro@200.173.254.14) has joined #cherrypy
Nov 16 19:52:47 <cribeiro>	Hi!
Nov 16 19:52:49 <Remi>	Or writing more library modules, or filters, or applications
Nov 16 19:52:51 <Remi>	Hi Carlos
Nov 16 19:54:08 <cribeiro>	news?
Nov 16 19:55:09 <Remi>	Well, we're just talking about ways to improve/make more popular CP
Nov 16 19:55:41 <Lawouach_>	we take apache and we rename it CherryPy ?
Nov 16 19:56:08 <cribeiro>	What about calling it... Zope 4 ;-) ???
Nov 16 19:56:17 <Lawouach_>	eh eh, finally a good zope release
Nov 16 19:57:16 <cribeiro>	Now serious. What about migrating the CherryPy site to CP2 itself? I know Remi wants to do it... 
Nov 16 19:57:43 <Lawouach_>	it would make sense yes
Nov 16 19:57:43 <cribeiro>	My idea is to make the CherryPy site a good showcase for CP technology
Nov 16 19:58:00 <martin>	Of course docs are important, but a nice lookin killer example would do wonders, any designers around ?
Nov 16 19:58:12 <Remi>	Well, I want to make it possible for people to update the cherrypy.org easily ...
Nov 16 19:58:43 <Remi>	So unless we first write a wiki or CMS in CP, I'd rather keep it as it is ...
Nov 16 19:59:09 <Remi>	Nothing prevents from having a separate "showroom" site...
Nov 16 19:59:22 <cribeiro>	Humm. May I give one idea? I fear it may get long...
Nov 16 19:59:37 <Lawouach_>	I plane to write a CMS for cP2 but it won't be before next spring
Nov 16 19:59:43 <cribeiro>	My point (which Remi already touched briefly) is as this:
Nov 16 20:00:06 <cribeiro>	1) write some generic modules for CP2, for common CMS stuff.
Nov 16 20:00:11 <cribeiro>	At least a blog module and a Wiki module.
Nov 16 20:00:55 <cribeiro>	2) implement these modules in such a way that they can be published as parts of a bigger CP2 application.
Nov 16 20:01:50 <cribeiro>	My idea is that, inside the same site, it would be possible to host several blogs... or several wikis...
Nov 16 20:03:05 <Remi>	but there are already tons of these ... (pyds for instance)
Nov 16 20:05:19 <Lawouach_>	the main pb of doing that carlos is that it will force to maitain those apps
Nov 16 20:05:25 <Lawouach_>	which we may not have the time for
Nov 16 20:05:39 <Lawouach_>	keeping it simple but efficient would be much easier for the CP community
Nov 16 20:05:40 <Remi>	I think that having some real-world websites that use it, writing some good documentation and do a bit of propaganda should be a good start ...
Nov 16 20:06:01 <Lawouach_>	Remi, I quite agree and it sets closer expectations
Nov 16 20:06:07 <Lawouach_>	at least more realistic on the short term
Nov 16 20:08:16 <cribeiro>	But pyds is not for CherryPy :-) 
Nov 16 20:09:11 <slate>	Hello
Nov 16 20:09:12 <cribeiro>	A clarification. I don't assume that the CMS part (blog & wiki) are part of the main CP project.
Nov 16 20:09:13 <Remi>	True ... Well, if you want to give it a shot, feel free to do it :-)
Nov 16 20:09:23 <Remi>	Hi slate
Nov 16 20:09:25 <slate>	How about a statesafe implementation.
Nov 16 20:09:29 <Remi>	Carlos: sure
Nov 16 20:09:37 <slate>	I wrote it into the wishlist.
Nov 16 20:09:44 <cribeiro>	I was thinking more along the lines of user-contributed code. Simple code, really. 
Nov 16 20:10:03 <Remi>	Carlos: Sure, like the Zope "products" ...
Nov 16 20:10:44 <Lawouach_>	slate : what do you mean ?
Nov 16 20:11:03 <slate>	it is explained on eleven.org
Nov 16 20:11:12 <slate>	http://eleven.org
Nov 16 20:11:14 <cribeiro>	Remi: yep. but CP2 is *so* much easier to use than Zope. To install a product, for instance... just import the module and attach it to the tree. 
Nov 16 20:11:35 <slate>	sorry
Nov 16 20:11:36 <slate>	http://eleven.sourceforge.net/
Nov 16 20:11:44 <cribeiro>	There are two issues wrt to "products" that Zope does that have to be done by CP2.
Nov 16 20:12:42 <cribeiro>	(1) a site-wide user authentication framework. Now that we have filters... it can a product on its own.
Nov 16 20:13:13 <cribeiro>	(2) better hooks to store config info for 'products'. 
Nov 16 20:14:58 <Remi>	Carlos: true, but the idea is the same, right ? I agree that it would be nice to have a large "library" of modules ...
Nov 16 20:15:16 -->	vargas (~berstein@bobillot-3-82-67-147-69.fbx.proxad.net) has joined #cherrypy
Nov 16 20:15:37 <cribeiro>	Remi: yes. I agree that this is a long term goal. But having a roadmap helps.
Nov 16 20:17:14 <Lawouach_>	carlos, if we start writing to many modules, we will have to maintain them as well... which can lead in a lof of work which might not be the primary goal of Remi, and in general of the CP community
Nov 16 20:17:20 <Lawouach_>	though it would be nice surely
Nov 16 20:18:28 <Remi>	Well, my plan is to have "unofficiel third-party modules", and then "official modules", that are distributed with CherryPy itself.
Nov 16 20:19:11 <cribeiro>	Lawouach: Trying to do too many things at once is a recipe for failure :-)
Nov 16 20:19:13 <Lawouach_>	slate, the eleven project sounds interesting but the guy seems really to confident, it scares me a bit ;)
Nov 16 20:19:27 <Lawouach_>	cribeiro, exactly I agree
Nov 16 20:19:39 <Lawouach_>	so I'd rather make sure CP2 is fully tested
Nov 16 20:19:45 <Lawouach_>	and does what it is exepected to
Nov 16 20:19:47 <Lawouach_>	do
Nov 16 20:19:55 <Lawouach_>	and that it has a good documentation
Nov 16 20:19:56 <slate>	Lawouach_, is that your expert opinion?:)
Nov 16 20:20:00 <Lawouach_>	it's boring as hell I know
Nov 16 20:20:08 <Lawouach_>	slate, surely not :)
Nov 16 20:20:21 <cribeiro>	Lawouach: But I still think that we could have *at least* a blog and a wiki module. No database -- just a filesystem store.
Nov 16 20:20:57 <Lawouach_>	sure
Nov 16 20:21:04 <Lawouach_>	it wouldn't require too much effort I suppose
Nov 16 20:21:05 <Lawouach_>	:)
Nov 16 20:21:24 <cribeiro>	Its mostly a matter of not setting expectations too high
Nov 16 20:21:34 <cribeiro>	I mean, a simple blog & a simple wiki
Nov 16 20:21:57 <cribeiro>	No complex APIs, and simple templating (with CherryTemplate)
Nov 16 20:24:34 <cribeiro>	(about eleven) Nice project. In fact... I am doing something similar in some ways.
Nov 16 20:25:33 <Remi>	Carlos: Sure, go for it :-)  A few people had written similar small apps for CP1 (for instance, Jeff Clement wrote a small contact management app: http://www.jclement.ca/software/jcard2/)
Nov 16 20:26:30 <cribeiro>	Remi: Hey! I didn't mean to write it all myself :-)
Nov 16 20:26:43 <cribeiro>	(I know, I deserve it, I must have kept my mouth shut :-)
Nov 16 20:32:52 <--	vargas has quit (Quit: Leaving)
Nov 16 20:32:53 -->	vargas (~berstein@bobillot-3-82-67-147-69.fbx.proxad.net) has joined #cherrypy
Nov 16 20:34:56 <Remi>	Carlos: well, if you need other people then it's a regular open-source community project: get started, publish something and hope that people help you :-)
Nov 16 20:36:09 <vargas>	Hello, glad to salute you all
Nov 16 20:36:39 <Remi>	Hi vargas
Nov 16 20:36:53 <vargas>	Bonjour Remi ;)
Nov 16 20:39:21 <Remi>	I just added the first 2 recipes on the website
Nov 16 20:41:26 <vargas>	Nice
Nov 16 20:42:12 <slate>	Remi, I think its better that you attach the file to the recipe
Nov 16 20:44:46 <Remi>	slate: well, code samples in reciped should be quite small so I think it's better if they're inline (with syntax highlighting). This allows people to take a quick glance at it
Nov 16 20:44:56 <Remi>	If they want to use it, they can easily copy and paste it
Nov 16 20:45:27 <slate>	konqueror doesnt support gzip:(
Nov 16 20:47:41 <Remi>	really ? That's pretty bad ...
Nov 16 20:47:57 <Remi>	The GzipFilter handles that anyway
Nov 16 20:48:03 <cribeiro>	Remi: I'll contribute my current project to CP, as soon as it gets stable enough.
Nov 16 20:48:29 <cribeiro>	It's a workflow engine. (that's why I said that it was similar to Eleven in some ways)
Nov 16 20:48:50 <Remi>	cool. what do you mean by "workflow engine" ?
Nov 16 20:49:00 <vargas>	Like publishing?
Nov 16 20:49:08 <slate>	petri nets?
Nov 16 20:49:14 <cribeiro>	It's an fully data-driven application. Yes, it uses Petri nets.
Nov 16 20:50:37 <cribeiro>	Each user has a list of open tasks to work with. Tasks are automatically sequenced in the system. At any point, a copy of the last snapshot is available.
Nov 16 20:52:00 <slate>	cool. I will look at it.
Nov 16 20:52:14 <cribeiro>	There is a excellent document about Petri nets at http://www.tonymarston.net/php-mysql/workflow.html
Nov 16 20:53:04 <cribeiro>	The link is for a PHP app. My model is slight different, but the basics are the same.
Nov 16 20:53:46 <cribeiro>	I am having a *lot* of work to mak sure that the application does not become tied to its now only and single customer :-)
Nov 16 20:54:08 <cribeiro>	...so I hope to be able to contribute it pretty soon.
Nov 16 20:54:22 <cribeiro>	BTW, that's why I never find time to finish the URL mapping...
Nov 16 20:54:54 <cribeiro>	...but on the other hand, the workflow app was the original reason to implement it (and Stefano's patch for virtual args)
Nov 16 20:55:10 <Remi>	well, I can finish it if you don't have time ...
Nov 16 20:55:44 <cribeiro>	Remi: well, the problem is that I am using a home-baked version on my own CP server now. A branch of sorts.
Nov 16 20:56:30 <cribeiro>	Besides that, there is an issue...
Nov 16 20:56:42 <cribeiro>	Remember the old "trailing slash" discussion?
Nov 16 20:56:49 <Remi>	yes
Nov 16 20:57:23 <cribeiro>	I had to add two extra cases for it to work for me.
Nov 16 20:57:36 <Remi>	which ones ?
Nov 16 20:57:50 <cribeiro>	The same ones we had discussed back then :-)
Nov 16 20:58:28 <cribeiro>	(1) if the URL has a trailing slash, try index() first. If it can't find it, try default(), calling it with a empty string as the first parameter.
Nov 16 20:58:42 <Remi>	right
Nov 16 20:58:52 <cribeiro>	The difference is that (as per the agreement) there was no fallback to default.
Nov 16 20:59:13 <cribeiro>	Imagine a situation...
Nov 16 20:59:37 <cribeiro>	My workflow engine is today implemented as the "root" of my CP2 application.
Nov 16 20:59:53 <cribeiro>	In this case, it has to implement the "index()" method. Ok?
Nov 16 21:00:58 <cribeiro>	...but now, I want to add more features, and the workflow is not the root anymore. Let's say I add a static root  page.
Nov 16 21:00:59 <Remi>	right
Nov 16 21:01:37 <cribeiro>	Now, the user will type (or link to) http://mydomain/workflow (without the trailing slash).
Nov 16 21:01:50 <cribeiro>	So I have to implement the default() method in this case. Right?
Nov 16 21:02:49 <Remi>	hmm ...
Nov 16 21:02:53 <cribeiro>	What happens is that my 'product' ends up needing to provide two methods -- default and index -- but just one of the two will be called, depending on where is the application positioned in the published tree.
Nov 16 21:04:11 <cribeiro>	One solution that crossed my mind is really "radical". Why not unify default() and index()? (please! flames off!)
Nov 16 21:04:39 <cribeiro>	Did you all follow?
Nov 16 21:05:07 <Remi>	i did :-)
Nov 16 21:05:29 <cribeiro>	(did the others run into despair? :-)
Nov 16 21:05:46 <Lawouach_>	:)
Nov 16 21:06:00 <Lawouach_>	<cribeiro> One solution that crossed my mind is really "radical". Why not unify default() and index()? (please! flames off!) <-- i agree
Nov 16 21:06:16 <Lawouach_>	as I haven't yet seen the main advantage of havin,g default and index 
Nov 16 21:07:09 <cribeiro>	That's the point. For some reason, I always manage to find a way to solve my needs with index() alone.
Nov 16 21:07:27 <cribeiro>	But I can't speak for others...
Nov 16 21:08:09 <Lawouach_>	weel, I haven't really coded a lot with CP2 so I cannot tell if it is really useless but so far I haven't found any good side to it
Nov 16 21:08:18 <cribeiro>	Remi?
Nov 16 21:08:43 <slate>	isnt the default for handling 404?
Nov 16 21:09:46 <Remi>	well
Nov 16 21:09:57 <Remi>	I *do* want to keep default *and* index
Nov 16 21:10:32 <Lawouach_>	ok fair enough then
Nov 16 21:10:34 <Lawouach_>	:)
Nov 16 21:10:54 <Remi>	To me, the difference between the 2 is huge: one means that an object was found for the URL, one means that no object was found ...
Nov 16 21:11:37 <Lawouach_>	with that simple sentence you clarified a lot of my issues remi !
Nov 16 21:11:38 <Remi>	Carlos: for your problem, the URL to your app is: http://mydomain/workflow/, *with* a trailing slash
Nov 16 21:12:14 <cribeiro>	I'm not really convinced. But I'll not fight (very much)
Nov 16 21:13:50 <slate>	I think its better a design issue.
Nov 16 21:13:59 <cribeiro>	Please be patient. I promise I'll not raise this issue again later on. Assume for a moment that you had index alone. 
Nov 16 21:14:25 <cribeiro>	If you look at it *in practice*, you'll see that it does not matter that much.
Nov 16 21:15:10 <Remi>	Well, I can see your point that it would be nice to just distribute a module and then people can just "mount" it by typing "cpg.root.module = Module()"
Nov 16 21:15:26 <cribeiro>	Remi: yes. that's the point.
Nov 16 21:15:27 <Remi>	And then people can access it through http://domain/module (without a trailing slash)
Nov 16 21:15:53 <cribeiro>	In fact.. people can mount & unmount it dinamically.
Nov 16 21:15:54 <Remi>	Well, I guess we could go back to the way CP1 was working then ...
Nov 16 21:16:20 <Lawouach_>	what I don't get is, why don't we just remove the trailing slash and never bother with it ?
Nov 16 21:16:36 <Remi>	First try cpg.root.module.index(), and then cpg.root.module()
Nov 16 21:16:42 <cribeiro>	Lawouach: There was another long discussion some time ago about it.
Nov 16 21:17:28 <cribeiro>	Remi: the CP1 way isnt well suited to the lookahead search as I have implemented it.
Nov 16 21:17:47 <cribeiro>	The cpg.root.module() would be found *before* the index was ever checked.
Nov 16 21:18:41 <cribeiro>	Lawoauch: the problem is that sometimes it does make a difference whether you have or not a trailing slash. Apache does treat it differently, as do other frameworks (Zope, I think, does it)
Nov 16 21:19:15 <Remi>	Well, Apache serves files and directories, which is different ... I don't know about Zope
Nov 16 21:19:35 <slate>	if we treat it the same then there can be naming conflicts.
Nov 16 21:19:36 <cribeiro>	Remi: Forget what I said about Zope. It was  *long* time since I last messed with it.
Nov 16 21:19:53 <Remi>	Try this: go to http://directory.google.com/Top/Computers/
Nov 16 21:19:59 <Remi>	Then remove the trailing slash ...
Nov 16 21:20:01 <cribeiro>	The weird thing is that CP1 and CP2 works as it is now. :-)
Nov 16 21:20:21 <Remi>	You still get the same page and it doesn't do a redirect ...
Nov 16 21:21:21 <Remi>	The argument against doing this is that now you have two URLs corresponding to the same page whereas they should in theory correspond to different "ressources"
Nov 16 21:21:30 <cribeiro>	Weird. I dont know about you. The apge is *almost* the same, but for me it gives aslightly different formatting for the middle columns.
Nov 16 21:21:57 <Lawouach_>	the page is the same on my side
Nov 16 21:22:00 <cribeiro>	Remi: yes, that was the point.
Nov 16 21:22:26 <cribeiro>	well, the page is the same for all practical purposes here too. It's only a small formatting glitch. Weird.
Nov 16 21:22:27 <Remi>	But I think that's being too idealistic and it is more practical to not really care about the trailing slash
Nov 16 21:23:12 <cribeiro>	How about just passing the trailing slash as an empty string? This way, the handling method would be able to know whether it was called with a trailing slash or not.
Nov 16 21:23:14 <Remi>	carlos: I noticed the small change too, but if you just do a reload, it sometimes changes too ... I gues it depends which of the 100000 servers you're hitting ;-)
Nov 16 21:23:24 <Lawouach_>	well it is only a matter of deciding a way and to stick to it. period.
Nov 16 21:23:53 <slate>	there is a big difference in this url.
Nov 16 21:24:05 <Remi>	well, let's revist the "mapping algorithm" then ...
Nov 16 21:24:06 <slate>	wget gets the same file
Nov 16 21:24:17 <slate>	but saves on different names.
Nov 16 21:24:24 <cribeiro>	As I was talking... The weird thing is that CP1 and CP2 works as it is now. And messing with it is *much* harder than it seems at first.
Nov 16 21:25:09 <cribeiro>	Perhaps we can nail it for good. 
Nov 16 21:25:29 <Remi>	But CP1 didn't have "default"
Nov 16 21:25:50 <cribeiro>	Remi :-) That's my point. I don't think we *need* to have default :-)
Nov 16 21:26:41 <Remi>	I think having "default" is a nice feature. It is useful for the new kinds of URLs that people are using, like http://myblog/year/month/day
Nov 16 21:26:49 <cribeiro>	(unless default is a substitute for a 404 handler... ?)
Nov 16 21:27:03 <Remi>	Instead of the old style: http://myblog?date=year-month-day
Nov 16 21:27:06 <cribeiro>	Remi: but we can do it with index() just as nicely.
Nov 16 21:27:34 <cribeiro>	myblog.index(year=2004, month=11, day=16)
Nov 16 21:28:32 <Remi>	But I also want to be able to use "default" to say "sorry, page not found". And I don't want to stick that code in "index"
Nov 16 21:29:02 <cribeiro>	Well. So we are talking about different things here. No wonder it's so hard to get an agreement.
Nov 16 21:29:13 <cribeiro>	What you want is a 404 handler. Right?
Nov 16 21:29:35 <slate>	a smart one:)
Nov 16 21:29:49 <cribeiro>	It makes a lot of difference...
Nov 16 21:30:29 <Remi>	No, what I want is a clear distinction between "this method is being called because it is the one that corresponds to the URL" or "the method that corresponds to the URL doesn't exist so I am calling this other method instead"
Nov 16 21:31:12 <Lawouach_>	Remi, shouldn't it be an abstract method then instead ?
Nov 16 21:31:22 <Lawouach_>	instead of being a method of the classes itself ?
Nov 16 21:31:34 <cribeiro>	Remi: again, forgive me. I've been writing test cases for it for a few weeks now. It does not make a difference. Really. Believe me...
Nov 16 21:31:38 <Lawouach_>	or even maybe create a filter to handle the HTTP code
Nov 16 21:32:06 <Remi>	Now, depending on how people build their application and use URLs, they might *deliberately* make use of "default", or it may be called because someone typed a bad URL ...
Nov 16 21:32:46 <cribeiro>	I don't think that default should be "abused" like this. What matter most, in this case, is the intention of the designer.
Nov 16 21:33:05 <cribeiro>	Lets keep it simple.
Nov 16 21:33:32 <cribeiro>	The simplest CP application will have only one default() method at the root, acting as a 4040 handler for the entire application.
Nov 16 21:33:42 <cribeiro>	/4040/404
Nov 16 21:34:00 <Remi>	True. Or not default at all and catch cperror.NotFound in _cpOnError
Nov 16 21:34:08 <cribeiro>	Yep.
Nov 16 21:34:15 <--	vargas has quit (Remote host closed the connection)
Nov 16 21:34:55 <cribeiro>	Now, if the user *wants* to do real processing on arbitrary URLs, it's simply a matter of declaring a suitable index() method that takes the extra arguments.
Nov 16 21:35:22 <Remi>	I don't want "index" to act as default because it means that every "index" method would need to check if some extra arguments are being passed and raise a special exception if it's the case ...
Nov 16 21:35:27 <cribeiro>	The default(), in this case, is *never* the preferred method for mapping, but a last resort method.
Nov 16 21:35:28 <Remi>	It is not the role of "index"
Nov 16 21:36:21 <Lawouach_>	Then I believe we should create a specific HTTP code handler in order to be consistant. I mean let's say that you want to be able to send a specific message when you get a different 40x error code, or a 50x, etc.
Nov 16 21:36:52 <Remi>	Well, that's a different issue ...
Nov 16 21:36:58 <Lawouach_>	not really
Nov 16 21:36:59 <cribeiro>	Calling default do to processing on arbitrary parameters is not the same thing as processing a 404.
Nov 16 21:37:09 <Lawouach_>	why giving a special role to a 404 ?
Nov 16 21:37:20 <cribeiro>	So I agree with Remi (at least on this :-)
Nov 16 21:37:23 <Remi>	Hold on ... Let's try to be methodic :-)
Nov 16 21:37:25 <Lawouach_>	:)
Nov 16 21:37:27 <Lawouach_>	ok
Nov 16 21:37:53 <Remi>	First, do we agree on this: it is not the role of "index" to trap badly typed URL  ?
Nov 16 21:38:02 <cribeiro>	Yes.
Nov 16 21:38:17 <Lawouach_>	Yes
Nov 16 21:38:47 <Remi>	In that case, "index" shouldn't be called if someone adds some extra "directories" to the URL, right ?
Nov 16 21:39:10 <cribeiro>	Humm. A leap of faith, perhaps :-) But I see your point, and it's where we seem to disagree now.
Nov 16 21:39:42 <Lawouach_>	Remi, do you have a quick and dirty sample ?
Nov 16 21:40:04 <Remi>	The problem is that we can't know if these extra directories where expected or not ...
Nov 16 21:40:09 <cribeiro>	It would be much easier, if not for the annoying special case of the root object.
Nov 16 21:40:55 <cribeiro>	Remi: You can know if they were expected or not. The inspect module has such functionality.
Nov 16 21:41:22 <cribeiro>	May i suggest one alternative?
Nov 16 21:41:25 <Remi>	Carlos: I really don't want to get into that ...
Nov 16 21:41:29 <Remi>	(introspect)
Nov 16 21:41:38 <Remi>	sure :-)
Nov 16 21:41:45 <cribeiro>	It's not as bad as it seem. And for the end user, the code reads clean.
Nov 16 21:41:59 <cribeiro>	Well. I know that introspection is hard stuff. 
Nov 16 21:42:29 <cribeiro>	My idea is: if the index method allow the extra parameters, then call it. If it does not allows it, then calls the error handler.
Nov 16 21:42:44 <cribeiro>	No "guesses" as to what should be called.
Nov 16 21:43:11 <cribeiro>	...and you get a solid guarantee that the application is not easily broken by malformed URLs.
Nov 16 21:43:50 <cribeiro>	What I can say is that the inspect module is *surprisingly* easy and clean to work with. No black magic is involved.
Nov 16 21:44:12 <Remi>	Also, how would you distinguish between keyword arguments and non-keyword arguments ?
Nov 16 21:44:27 <cribeiro>	Remi: Piece of cake :-) Wait a moment...
Nov 16 21:44:45 <Remi>	I mean, if my method is like this: def index(self, year, month, day, extrarg)
Nov 16 21:45:13 <Remi>	and someone goes to index/year/month/year/crap, then extraarg will have the value "crap", right ?
Nov 16 21:45:40 <cribeiro>	inspect.getargspec
Nov 16 21:45:49 <cribeiro>	 Get the names and default values of a function's arguments. A tuple of four things is returned: (args, varargs, varkw, defaults). args is a list of the argument names (it may contain nested lists). varargs and varkw are the names of the * and ** arguments or None. defaults is a tuple of default argument values; if this tuple has n elements, they correspond to the last n elements listed in args.
Nov 16 21:45:58 <Remi>	and if someone goes to index/year/month/day?extraarg=crap, then the same thing will happen, right ?
Nov 16 21:46:07 <cribeiro>	Yes. The same thing.
Nov 16 21:46:19 <cribeiro>	(no)
Nov 16 21:46:33 <cribeiro>	It depends on the actual design... a little bit.
Nov 16 21:46:58 <Remi>	how about index/year/month/day?month=12 ?
Nov 16 21:47:13 <slate>	:))
Nov 16 21:47:20 <cribeiro>	Wait a moment...
Nov 16 21:47:37 <cribeiro>	(a couple of minutes)
Nov 16 21:49:25 <Lawouach_>	Remi, such a case is not meant to be dealt by the app developer IMO
Nov 16 21:49:34 <Lawouach_>	it has to be dealt by CP itself
Nov 16 21:49:43 <Lawouach_>	I mean otherwise it is endless
Nov 16 21:50:00 <cribeiro>	I am writing a small test app...
Nov 16 21:50:32 <cribeiro>	But I see Lawouach point. CP2 can only do a part of the stuff. Corner cases *are* corner cases.
Nov 16 21:50:43 <cribeiro>	(just a moment...)
Nov 16 21:53:37 <cribeiro>	index is declared as: "def index(year=2004, month=12, day=1)"
Nov 16 21:53:51 <cribeiro>	(['year', 'month', 'day'], None, None, (2004, 12, 1))
Nov 16 21:54:08 <cribeiro>	(the line above is the getargspec output)
Nov 16 21:56:10 <cribeiro>	Looking at the line above, we can see that the function expects at most three parameters. So if the URL contains a fourth parameter, we can safely dismiss it.
Nov 16 21:56:34 <cribeiro>	Now, the function may be correctly called as:
Nov 16 21:56:37 -->	sja (~chat@host38-81.pool80181.interbusiness.it) has joined #cherrypy
Nov 16 21:57:00 <cribeiro>	http://mydomain/year/month/day
Nov 16 21:57:29 <cribeiro>	or... http://mydomain?year=x&month=y&day=z
Nov 16 21:57:42 <cribeiro>	Validation, of course, is not for CP2 to handle. But it can count the parameters.
Nov 16 21:57:47 <Lawouach_>	what happens if you do http://mydomain?param=useless&year=x&month=y&day=z
Nov 16 21:58:46 <cribeiro>	Lawouach: the same as it would happen for CP1 or CP2. The index() method does not expect to receive a keyword parameter named 'param'. It will fail on call. But that's what it does now.
Nov 16 21:59:03 <cribeiro>	I'm not (overly) concerned with keyword parameters. 
Nov 16 21:59:17 <cribeiro>	...because they already are implemented like that anyway...
Nov 16 22:00:19 <cribeiro>	def index(year=2004, month=12, day=1, *kw): pass
Nov 16 22:00:25 <cribeiro>	(now with a kw parameter)
Nov 16 22:00:41 <cribeiro>	getargspec() -> (['year', 'month', 'day'], 'kw', None, (2004, 12, 1))
Nov 16 22:01:01 <cribeiro>	Now the kw parameter is annotated, so we can see that is safe to pass arbitrary parameters.
Nov 16 22:01:05 <cribeiro>	remi?
Nov 16 22:01:15 <sja>	you missed an asterisk: **kw
Nov 16 22:01:45 <cribeiro>	Sure. (argh!) So the result is slightly different.
Nov 16 22:01:58 <cribeiro>	(['year', 'month', 'day'], None, 'kw', (2004, 12, 1))
Nov 16 22:02:05 <Remi>	hmm ...
Nov 16 22:02:20 <sja>	what's the topic?
Nov 16 22:02:29 <cribeiro>	Good questiont :-)
Nov 16 22:02:37 <Remi>	but then how do you distinguish between "page doesn't exist" and "unexpected argument" ?
Nov 16 22:02:59 <Lawouach_>	hi sja 
Nov 16 22:03:08 <sja>	hi Sylvain
Nov 16 22:03:45 <cribeiro>	sja: we are discussing, hopefully for the last time this year, how to properly do URL mapping, default, index and 404 error handling... not to mention error cheking on brain-dead URLs.
Nov 16 22:04:10 <cribeiro>	Remi: let me think for a moment :-)
Nov 16 22:04:10 <sja>	hehe, that's my speciality :-D
Nov 16 22:04:24 <cribeiro>	I have made a bold proposition...
Nov 16 22:05:22 <cribeiro>	(1) make index() the preferred method to handle arbitrary URLs (including the ones with extra positional args)
Nov 16 22:06:00 <cribeiro>	(2) use the inspect module to check the method signature before the call, so CP will know whether to call index, or to resort to an error method.
Nov 16 22:06:47 <sja>	does checking the signature let you catch errors that a normal call wouldn't raise?
Nov 16 22:06:56 <cribeiro>	*If* index takes extra path items as arguments (as in the /year/month example)...
Nov 16 22:08:01 <cribeiro>	... I dont think that "page doesn't exist will be an issue". May you construct such a case?
Nov 16 22:08:31 <cribeiro>	(sorry, misplaced quotes, but I hope you get it).
Nov 16 22:08:45 <cribeiro>	sja: (about signature checking)
Nov 16 22:09:01 <Remi>	well, if I have "def index(self, pageNb)"
Nov 16 22:09:05 <cribeiro>	sja: I think that is better, in this situation, to check before yo jump :-)
Nov 16 22:09:22 <Remi>	and now someone types "http://domain/someCrap"
Nov 16 22:09:33 <Remi>	then CP will call index('someCrap'), right ?
Nov 16 22:09:45 <cribeiro>	It will handle any page. Isn't what it is supposed to do?
Nov 16 22:10:26 <Remi>	Well, it's supposed to be called like this: http://domain?pageNb=1, or http://domain?pageNb=2, ...
Nov 16 22:10:28 <cribeiro>	If you don't want your index method to be called, declare it as "def index(self)"
Nov 16 22:10:56 <Remi>	So the first thing "index" will do is probably "pageNb = int(pageNb)" for instance
Nov 16 22:11:08 <cribeiro>	In this case... I assume that the declaration should be: def index(self, **kw)
Nov 16 22:11:13 <sja>	yep
Nov 16 22:11:27 <cribeiro>	In this case, the getargspec will return the following:
Nov 16 22:11:50 <cribeiro>	(['self'], None, 'kw', None)
Nov 16 22:11:51 <Remi>	but then you have to type "pageNb = kw['pageNb']" :-(
Nov 16 22:12:10 <cribeiro>	Yes. But that's how it's done today, isn't it?
Nov 16 22:12:29 <Remi>	It's just too nice to be able to type "def index(self, pageNb)" and to have pageNb set automatically for you ...
Nov 16 22:12:38 <cribeiro>	...specially because there are GET & PÃ’ST issues to handle...
Nov 16 22:12:45 <sja>	I think it all boils down to this: which is the most common scenario? which one should we make easier to type?
Nov 16 22:12:57 <sja>	?par=xxx or /xxx ?
Nov 16 22:13:11 <cribeiro>	It may be a matter of style...
Nov 16 22:13:30 <sja>	in CP1 the ?par=xxx style was the favored one, the other style was quite hard to do
Nov 16 22:13:36 <Lawouach_>	why don't we convert on the ly internally to one or the other and we only work on one form
Nov 16 22:13:42 <Lawouach_>	for instance the ?par=value
Nov 16 22:13:55 <Lawouach_>	so we would ocnvert first the case /par/value to ?par=value
Nov 16 22:13:58 <cribeiro>	I prefer the /xxx way... it makes for nicer URLs to bookmark :-) and for some reason, I think that it's more 'search engine friendly'.
Nov 16 22:14:03 <Lawouach_>	as mod_rewrite does I assume
Nov 16 22:14:12 <Lawouach_>	cribeiro, sure doesn't bother me
Nov 16 22:14:15 <sja>	I prefer the /xxx way too
Nov 16 22:14:24 <Lawouach_>	my point is why don't we stick to one way internally
Nov 16 22:14:27 <Lawouach_>	?
Nov 16 22:14:30 <sja>	though there are cases where ? is more appropriate, /xxx is by far the most common
Nov 16 22:14:52 <cribeiro>	I think that the ? syntax invites the user to test crash the system :-)
Nov 16 22:15:13 <cribeiro>	(you know -- let's see and try what it can accept.)
Nov 16 22:15:16 <sja>	the /xxx looks more solid and professional :-D
Nov 16 22:15:24 <cribeiro>	(it's a problem for public services)
Nov 16 22:15:56 <Remi>	Well, let's not have a debate over which one is better ... CP should allow people to use both easily.
Nov 16 22:16:04 <sja>	Remi: we have to compromise
Nov 16 22:16:10 <sja>	one way has to be easier than the other
Nov 16 22:16:30 <sja>	making one easier makes the other slightly more difficult, we can't escape that
Nov 16 22:16:31 <cribeiro>	Not exactly "easier". One may be more natural, but both can be easy enough.
Nov 16 22:16:37 <Lawouach_>	Remi, the app developer would have the choice
Nov 16 22:16:45 <Lawouach_>	CP would only deals with one
Nov 16 22:16:59 <Lawouach_>	we would have to write a small routine to convert between the two
Nov 16 22:17:11 <cribeiro>	I'm not sure that a routine is needed...
Nov 16 22:17:21 <cribeiro>	A suggestion (one more!)
Nov 16 22:17:35 <Lawouach_>	maybe not, I haven't really thought about it
Nov 16 22:17:40 <sja>	cribeiro: in your proposal default() would be dropped?
Nov 16 22:17:49 <Remi>	Hold on ... Are you suggesting that a single app should easily support *both* ?
Nov 16 22:18:07 <cribeiro>	Remi: not wure who are you asking?
Nov 16 22:18:10 <cribeiro>	Remi: not sure who are you asking?
Nov 16 22:18:46 <Remi>	Well, mostly Sylvain, since he talked about "Converting the 2" ...
Nov 16 22:18:51 <cribeiro>	sja: as it is now, yes. default() would not be needed, as index9) would handle partial URL matches.
Nov 16 22:18:58 <sja>	cribeiro: good :-D
Nov 16 22:19:07 <Lawouach_>	Remi, isn't it what mod_rewrite does already for Apache ?
Nov 16 22:19:20 <cribeiro>	Remi: I had the same doubt as you. There is no issue into "supporting two style"
Nov 16 22:19:34 <sja>	yep, Sylvain has drifted apart a bit :-)
Nov 16 22:19:50 *	Lawouach_ goes back to sleep
Nov 16 22:20:07 <cribeiro>	(about mod_rewrite) it's a totally different issue, and a filter can handle it... but thats OT now.
Nov 16 22:20:12 <Remi>	Sylvain: sure. you could do the conversion in CP, but I don't think CP should do that work for you ...
Nov 16 22:20:32 <Remi>	Anyway, a decision has to be made at some point ...
Nov 16 22:20:46 <cribeiro>	Back to track...
Nov 16 22:21:03 <cribeiro>	my proposal is that the recommended signature for the index method would become:
Nov 16 22:21:44 <cribeiro>	def index(<list of url-mappable-parameters>, **kw)
Nov 16 22:22:10 <sja>	index used like this bothers me... can we call it default? :-D
Nov 16 22:22:22 <Remi>	trouble-maker ;-)
Nov 16 22:22:24 <sja>	it's not really an "index" anymore...
Nov 16 22:22:26 <sja>	haha
Nov 16 22:22:29 <cribeiro>	if **kw is NOT provided, then the URL may sport *at most* the number of parameters as declared.
Nov 16 22:22:31 <sja>	I know, sorry :-)
Nov 16 22:22:36 <sja>	I'm a perfectionist! :-D
Nov 16 22:23:10 <cribeiro>	The problem is that we end with tow methods (index() and default()) that overlap a lot, to the point where it's not clear who should be handling what.
Nov 16 22:23:28 <sja>	cribeiro: I agree, we should have one... but let's call it default :-D
Nov 16 22:23:33 <Remi>	Anyway, it's getting late here so I have to make a decision ...
Nov 16 22:23:43 <cribeiro>	Right now? 
Nov 16 22:23:48 <cribeiro>	Another suggestion.
Nov 16 22:23:58 <Remi>	Well, I have a feeling we could go on and on and never agree ...
Nov 16 22:24:02 <cribeiro>	Create a branch on the repository where we can freely experiment with it.
Nov 16 22:24:14 <sja>	what's not to agree with? :-P
Nov 16 22:24:27 <cribeiro>	Remi: you're *totally* right in the sense that at some point a decision *has* to be made.
Nov 16 22:24:57 <Lawouach_>	yeah and the decision is to move to Tomcat !
Nov 16 22:25:05 <Lawouach_>	hmmm sorry I really need to sleep
Nov 16 22:25:13 <sja>	Lawouach_: I disagree, let's move to Nevow :-)
Nov 16 22:25:15 <cribeiro>	(who was the troublemaker? ;-)
Nov 16 22:25:17 <Lawouach_>	:)
Nov 16 22:25:19 <sja>	I am! :-D
Nov 16 22:25:34 <cribeiro>	Seriously guys. I am somewhat concerned about it ...
Nov 16 22:26:01 <sja>	if you consider the fact that I still haven't given up on the trailing slashes issue... then I'm the number one troublemaker :-D
Nov 16 22:26:12 <Remi>	carlos: sure, feel free to make a branch on your own ...
Nov 16 22:26:17 <cribeiro>	Having a branch is a compromise. It's a way we can make some experiments to check whether the result works naturally for us, in our own applications...
Nov 16 22:26:40 <cribeiro>	The trailing slash can be accomodated without messing with this discussion. Really.
Nov 16 22:26:41 <Remi>	But in the mean time, here is what I'm going to implement:
Nov 16 22:27:16 <Remi>	1- keep both index and default
Nov 16 22:27:39 <Remi>	1- keep both index and default (sorry carlos ;-)
Nov 16 22:27:50 <Remi>	2- ignore trailing slashes (sorry sja ;-)
Nov 16 22:27:55 <cribeiro>	I will feel more comfortable with a branch... because I will not be concerned about breaking someone else's code in the meantime.
Nov 16 22:28:28 <sja>	ow I miss Hendrik :-P
Nov 16 22:28:39 <Lawouach_>	what is doing BTW ?
Nov 16 22:28:39 <cribeiro>	But I would like to have some realistic expectation that the proposed change (index & default unification & signature checking) will be evaluated seriously.
Nov 16 22:28:54 <Remi>	carlos: sure. Do you want me to create branches in svn ? You should be able to do it on your own.
Nov 16 22:29:14 <cribeiro>	Yeas, now I can... :-) Having a Linux box to play is really nice. 
Nov 16 22:29:39 <cribeiro>	(for thos who don't know, I was suffering from Windows-ite up to a week ago :-P)
Nov 16 22:29:43 <Remi>	Having both index and default just means that if you want to use the /blog/year/month/day scheme, you have to work with "default" instead of "index"
Nov 16 22:30:09 <Lawouach_>	cribeiro, :)
Nov 16 22:30:10 <cribeiro>	Fine. This part of my patch is working.
Nov 16 22:30:15 <--	martin has quit (Ping timeout: 480 seconds)
Nov 16 22:30:37 <Remi>	Anyway, to put this into prospective, keep in mind that this debate only affect a very small portion of the URLs ...
Nov 16 22:30:44 <Remi>	Most URLs will be trivial to map to objects ...
Nov 16 22:30:49 <cribeiro>	Of course. 
Nov 16 22:31:15 <cribeiro>	But I dont entirely buy the "most" argument.. because of the nature of the applications, or at least, of the applications that I am writing right now.
Nov 16 22:31:51 <Remi>	Is is really that big of a deal that you'll implement "default" instead of "index" ?
Nov 16 22:32:08 <sja>	Remi: the trouble is that it's hard to understand the difference between them
Nov 16 22:32:12 <cribeiro>	I tend to rely on POST-style parameter passing (so the **kw works nicely for me), and positional parameters.
Nov 16 22:32:17 <sja>	extra unnecessary complexity for the noobs
Nov 16 22:32:19 <sja>	:-)
Nov 16 22:32:27 <cribeiro>	Also, it works differently when you're at the root.
Nov 16 22:33:18 <Remi>	No, root will also call "default" if "index" doesn't exist
Nov 16 22:33:51 <cribeiro>	(crying) that was my original argument :-( 
Nov 16 22:34:00 <Remi>	I might not have been clear, but the "default" method I'm proposing works exactly like the "index" method you're proposing ...
Nov 16 22:34:26 <Remi>	Except it will need at least *one* positional argument
Nov 16 22:34:27 <cribeiro>	(remember? I proposed usign default as a fallback to index(). You didnt agree. That was the starting point for todays discussion)
Nov 16 22:35:47 <cribeiro>	:-)
Nov 16 22:35:49 <Lawouach_>	OMG... :)
Nov 16 22:36:06 <Remi>	Anyway, FYI, here is what I am going to implement:
Nov 16 22:36:09 <Remi>	    # for /a/b?arg=val, we'll try:
Nov 16 22:36:09 <Remi>	    #   root.a.b.index(arg='val')
Nov 16 22:36:09 <Remi>	    #   root.a.b(arg='val')
Nov 16 22:36:09 <Remi>	    #   root.a.b.default(arg='val')
Nov 16 22:36:09 <Remi>	    #   root.a.default('b', arg='val')
Nov 16 22:36:10 <cribeiro>	Anyway. We could have solved it much earlier...
Nov 16 22:36:11 <Remi>	    #   root.default('a', 'b', arg='val')
Nov 16 22:36:29 <Remi>	# ignore trailing slashes
Nov 16 22:37:30 <cribeiro>	Now that we are almost over, a final question... what did you think about the "official" IRC meeting?
Nov 16 22:37:34 *	sja switches to Tomcat :-P
Nov 16 22:37:58 <cribeiro>	IMHO... it was good, and we would never manage to make an agreement by email.

Nov 16 22:38:32 <Remi>	well, it's nice to see there is some enthusiasm :-) And it's nice to see that people *care* ...
Nov 16 22:38:39 <cribeiro>	A lot
Nov 16 22:38:50 <slate>	I'll look out for the workflow
Nov 16 22:38:55 <cribeiro>	Sure.
Nov 16 22:39:11 <Remi>	And I got 3 new "recipes" during that time :-)
Nov 16 22:39:13 <Lawouach_>	It's nice to see the people are motivated and nice
Nov 16 22:39:20 <cribeiro>	It's something that I have been looking for for years. Literally.
Nov 16 22:39:40 <Lawouach_>	slate, could you expand please, I'm intrigued.
Nov 16 22:39:53 <cribeiro>	Are you going to post the IRC session log to the Wiki?
Nov 16 22:40:00 <slate>	Lawouach_, ??
Nov 16 22:40:12 <Lawouach_>	<slate> I'll look out for the workflow 
Nov 16 22:40:14 <cribeiro>	Lawouach: I assume that he was talking about my CP2 Workflow engine.
Nov 16 22:40:22 <Lawouach_>	cribeiro, ah ok
Nov 16 22:40:34 <Remi>	Does anybody have an IRC client that lets you copy and paste the whole session ?
Nov 16 22:40:45 <cribeiro>	My IRC client logs the session automatically.
Nov 16 22:40:55 <cribeiro>	But I just got the second half of it.
Nov 16 22:40:57 <slate>	Lawouach_, yes.
Nov 16 22:41:04 <Remi>	I can't find a way to do it with mIRC ... It only lets me select one page at a time :-(
Nov 16 22:41:14 <cribeiro>	? I'm sure it can do it.
Nov 16 22:41:17 <Lawouach_>	Remi, I guess you can enable logging
Nov 16 22:41:24 <Remi>	Unless there's a secret option I don't know about ...
Nov 16 22:41:25 <Lawouach_>	so that it will write evrything to a file.
Nov 16 22:41:33 <sja>	Opera saves it as a nice html file :-)
Nov 16 22:41:52 <sja>	or I could send my logging bot to this channel
Nov 16 22:41:56 <Lawouach_>	xchat lets me do it but for some reason it only logs in UTF-8...
Nov 16 22:41:59 <cribeiro>	Check if there is a save buffer or something similar. It will save the current session. In the future, you can enable logging. I can do it also...
Nov 16 22:42:03 <sja>	http://zio.attardi.org/
Nov 16 22:42:10 <sja>	those are logs made by my bot :-)
Nov 16 22:42:26 <cribeiro>	Next session?
Nov 16 22:43:43 <Lawouach_>	whenever you want :)