IRC session - 2005/02/09
18:07 < Remi> well, I wanted to talk about configuration/filters first
18:07 < Remi> Basically, my goal is to make some of these filters *always* in
18:07 < Remi> And then people can just turn them on/off through configuration
18:08 < Remi> But to do that
18:08 < Remi> They need to be able to turn them on/off for specific portions of their sites
18:08 < Remi> which is why I think we need a configuration scheme that works on a per PATH basis
18:09 < Carlos> Remi: did you read my message from today? I sent it about one hour ago...
18:09 < Remi> yes
18:09 < Carlos> I proposed a few rules for the config system. It's well aligned with your intention.
18:10 < Carlos> The idea is to make the config file mimic the cpg hierarchic structure.
18:10 < Carlos> so:
18:10 < Carlos> [root]
18:10 < MV> Why not keep on plugging the on the cpg hierarchy ?
18:11 < Remco> Remi, don't you think mixing the filter usage through code and config files makes things a bit confusing?
18:11 < Carlos> EncodingFilter = True
18:11 < Carlos> Remi, can I have a few words?
18:11 < Remi> carlos: I like that :-)
18:12 < Carlos> On the topic raised by MV & Remco. I did some considerations on my message.
18:12 < Carlos> The config file needs to strike a balance.
18:12 < Carlos> 1. Be easy & powerful enough for non programmers.
18:12 < Carlos> 2. Be a good learning path for novice programmers.
18:13 < Carlos> 3. Be difficult to abuse by experienced programmers, who should do advanced stuff in code.
18:13 < Remco> carlos, remi, may i respond to these 3 statements
18:13 < Carlos> Can we agree on these three rules?
18:13 < Remco> carlos, please let me respond
18:13 < Remi> carlos: I agree with 1 and 3, but I don't think 3 is a requirement
18:14 < Remi> go ahead remco
18:14 < Remco> on 1:
18:14 < Remco> if you want to configure filters using a config file,
18:14 < Remco> what do non-programmers have to do with it
18:14 < Remco> on 2:
18:14 < Remco> i agree
18:14 < Remco> on 3:
18:14 < Remco> there shall be prefereable only one way to do it
18:15 < Remco> so not using code and/or ini file .
18:15 < Remi> my turn :-)
18:15 < Remco> shoot :)
18:15 < Carlos> Remi: just one comment: (3) should be a generic goal. It's not an absolute requirement.
18:15 -!- gpciceri [~gpciceri@host112-35.pool80180.interbusiness.it] has joined #cherrypy
18:15 < Remi> carlos: can you finish the syntax you were proposing ?
18:15 < Carlos> Ok.
18:16 < Carlos> I dont have all the details. There are lots of things to debate. But anyway.
18:16 < Almad> newbie ot: easy not for non-programmers, but for programmers, who don't knew cherrypy yet
18:16 < Carlos> Almad: 1 is important...
18:16 < Carlos> Because I may release a CherryPy app, that will be installed and configured by a non-programmer.
18:16 < Carlos> Let's say - a blog based on CP.
18:17 < Carlos> As for (2) - it's important to me.
18:17 < Carlos> But back to Remi's question.
18:17 < Carlos> Syntax:
18:17 < Carlos> The config file should mimic the cpg tree. Each section is an object in the cpg tree, as in:
18:17 < Carlos> [server] -> contains the params that would go into the cpg.server object.
18:18 < Carlos> Stuff as threads, port number, etc.
18:18 < Carlos> [root]
18:18 < Carlos> contains the attributes of the cpg.root object.
18:18 < Carlos> Other objects, deep into the hierarchy, are written down as paths to the equivalent cpg member.
18:19 < Carlos> http://mydomain/blog -> cpg.root.blog -> [root.blog]
18:19 < Remco> carlos, remi, i have a note
18:19 < Carlos> I prefer to write the object using the dot notation...
18:19 < Carlos> ...because it allows programmers to slowly learn how to program it inside CherryPy.
18:19 < Carlos> In other words, we're giving them a good learning path.
18:19 < Carlos> ok?
18:20 < MV> If i may , if u want to work at the path lvl better to continue doing it from root setting attribute on your objects
18:20 < Carlos> MV: it may be, but I think that using section is cleaner...
18:20 < Remi> carlos: i like that
18:20 < Carlos> Remco: ?
18:21 < Remco> i agree with the proposed syntax
18:21 < Remco> but with one question
18:21 < Remco> or better a remark
18:21 < Carlos> I'm sure there are still lots of quesitons.
18:21 < Remco> what to do with the setup of filters?
18:21 < Carlos> Ah.
18:21 < Carlos> Let's proceed.
18:21 < Remco> like, some settings are no problem
18:21 < Remco> especially port number and stuff
18:21 < Remco> but if we set filters, with parameters,
18:22 < Carlos> I *sincerely* and personally believe that some limit on what can be done on the config is necessary...
18:22 < Remco> these can either be void, or a string or a number. What about callback functions?
18:22 < Remco> carlos, please proceed
18:22 < Carlos> So I'm divided by some issues here.
18:22 < Carlos> I would like to avoid evals & lambdas. But I can live with it if the majority decides otherwise.
18:23 < Carlos> The syntax is: attribute = value...
18:23 < Carlos> Where 'value' is a Python basic type. Integer, string, etc.
18:23 < Carlos> For filters, an exception needs to be made.
18:23 < Carlos> Two options. 1) Assuming that filters themselves have attributes...
18:23 < Carlos> [root]
18:24 < Carlos> EncodingFilter = True
18:24 < Carlos> EncodingFilter.encoding = 'latin1'
18:24 < Carlos> 2) Assuming that we can pass a tuple, as parameters to the constructor.
18:24 < Carlos> [root]
18:24 < Carlos> EncodingFilter = ('latin')
18:24 < Carlos> Of course, the exact details are open to debate.
18:24 < Carlos> ?
18:25 < Remi> I prefer:
18:25 < Remi> [root]
18:25 < Remi> encoding = on
18:25 < Remi> encodingType = latin1
18:25 < Carlos> Remi: assuming that I intend to do the same on code...
18:25 < Carlos> I should then write it as:
18:26 < Carlos> cpg.root.encodingType = 'latin1'
18:26 < Remco> remi, carlos, for my peace of mind, and understanding. Do we want this to replace the current
way of setting things up, or just a new config file format , and the regular code wise method is also still valid?
18:26 < Carlos> (Of course the config file doesn't need the quotes, my mistake)
18:26 < Jos> question: is there in the code an object named EncodingFilter? I like #1 if there is. How do the names in the config file map back to the actual filters?
18:26 < Carlos> Remi: I agree with Jos... for a couple reasons.
18:26 < Carlos> It makes the code the same.
18:27 < Remi> remco: you can still use the old way of setting up filters if you want
18:27 < Remco> remi, thank you
18:27 < Remi> remco: this new way will be used for the "default" filters that CherryPy will always have
18:27 < Carlos> I mean, the same for the config & the direct code.
18:27 < Remi> carlos and jos: each filter would know what its configuration options are
18:27 < Carlos> Also. It's easier if we leave the actual internal attributes for each filter itself to handle.
18:27 < Carlos> Remi: I was just writing that.
18:28 < Carlos> So I believe that <EncodingFilter.encoding = latin1> is better.
18:28 < Remco> i agree with carlos and jos. keep things close to the names in the code
18:28 < Carlos> Also - considering the usual Python notation...
18:29 < Carlos> EncodingFilter is the class... and the instance should be encodingFilter.
18:29 < Carlos> so:
18:29 < Jos> as a neophite to CP, the closer the config is to the code, the easier it will be for people to learn.
18:29 < Carlos> [root]
18:29 < Jos> as everyone has said ;)
18:29 < Remi> ok
18:29 < Carlos> encodingFilter.encoding = latin1
18:31 < Remi> in my mind, it was going to be up to the filter to read its own config options from the config
file
18:31 < Carlos> Remi: is it ok? of course there are still lots of details to take care of...
18:31 < Carlos> Remi: in this plan, it is, in a sense.
18:31 < Remi> but it looks like you want CherryPy to "pass" the options to the filter
18:31 < Remco> how would one exclude filters from a object tree?
18:31 < Carlos> When the 'attribute = value' is read...
18:31 < Carlos> we can simply get the attribute, and use a recursive getattr on it.
18:31 < Carlos> Filter names can be handled in either of two fashions.
18:32 < Carlos> We can bind the standard filters to the tree by default...
18:32 < Remi> how would you know if "latin1" needs to be a string, an integer, ...
18:32 < Carlos> No problem, I assume. The filter has a property named encoding. The property should handle the type cast.
18:32 < Carlos> The config file passes a string.
18:32 < Remi> ok
18:33 < Remco> carlos, this means the filter is instanciated. how would you fix it?
18:33 < Carlos> Well, there's another issue that we havent discussed yet. If we are going to have standard filters, WHEN are they going to be created?
18:33 < Remco> good point
18:34 < Carlos> When I do : 'from cherrypy import cpg'... am I getting all the filters with default values?
18:34 < Remi> by cherrypy, when the HTTP server starts
18:34 < Carlos> That's my best take...
18:34 < Carlos> No, it should be *before* it starts.
18:34 < Remco> jup
18:34 < Carlos> Because I can use my code to set or override them...
18:34 < Carlos> ok?
18:34 < Carlos> Oops.
18:35 < Carlos> cpg.root does not exist at this point :-(
18:35 < Carlos> Remi, any idea?
18:35 < Remi> Exactly. you need to have your object tree already.
18:35 < Remco> the current system allows setting filter attributes in the class statement. so the import would be the only place possible
18:35 < Carlos> So... let's play with it.
18:35 < Carlos> When the server starts, it checks the cpg.root._cpFilterList value.
18:35 < Remi> You won't be able to "override" them in your code. All you'll be able to do is to "disable" them with the config file (just don't turn any of them on)
18:36 < Carlos> If it's not set, then it comes up with default filters.
18:36 < Remi> carlos: that's not what I had in mind
18:36 < Remi> the default ones will be a separate list
18:36 < Carlos> But that's necessary if you want to keep the current _cpFilterList behavior, as Remco has asked.
18:36 < Carlos> So: if the user provides a list, he must provide a *full* list.
18:36 < Remi> no
18:37 < Carlos> If he doesn't provide anything, then the default gets into effect.
18:37 < Carlos> No?
18:37 < Carlos> :-(
18:37 < Remco> remi, i think this would obstruct obviousity (may be errors in spelling)
18:37 < Remi> We'll have 2 *default* lists: "beforeEverything" and "afterEverything"
18:37 < Remi> Then the actual list used will be beforeEverything + _cpFilterList + afterEverything
18:38 < Carlos> Humm. I see your point.
18:38 < Remco> remi, can those default filters be disabled in the configfile?
18:38 < Carlos> But I still think that my proposal is simpler. Can I restate it, in fewer words?
18:38 < Remco> or better, can they only be enabled if specified in the configfile?
18:39 < Remi> remco: they're not active unless you explicitely enable them in the config file
18:39 < Remi> Carlos: go ahead
18:39 < Remco> thnx
18:39 < Carlos> I have in mind the balance between ease for newbies & power for programmers.
18:40 < Carlos> SO :
18:40 < Carlos> If the user doesn't provide a _cpFilterList, CherryPy will automatically configured with its
own, default list.
18:40 < Carlos> If the user provide a _cpFilterList, it is assumed to be complete.
18:40 < Carlos> If the user wants *NO* filters, he must provide a empty list: _cpFilterList = []
18:41 < Carlos> And finally...
18:42 < Carlos> If the user wants to merge its own custom filters in the middle of the chain, he can use the
standard cpg.BeforeFilterList and cpg.AfterFilterList to build its own.
18:42 < Remco> carlos, "automatically configured with it's own" should read as "automatically configured using the config file" i guess?
18:42 < MV> Maybe make _cpFilterList a dic
18:42 < Carlos> Remco: yes & no :-)
18:42 < Carlos> MV: the filter list needs to be ordered. That's why it's a list.
18:42 < Carlos> But we need access by name to allow configuration.
18:42 < Remco> carlos: remi just stated if a filter wasn't used in the config file, it will not be loaded.
18:43 < Carlos> For the sake of good performance, and to keep newbies happy, the default set can come with good defaults.
18:43 < Carlos> Suggestion:
18:43 < Carlos> Zip is off; encoding is on, with utf-8 or latin1; caching is off.
18:44 < Carlos> Generators is on. But all these filters are in the list, but some are 'disabled'.
18:44 < Carlos> So newbies will get a suitable filter list...
18:44 < Carlos> and advanced programmers can totally override it.
18:44 < Carlos> ok?
18:44 < Remi> carlos: I still think we should *always* leave the default ones ...
18:44 < Remco> carlos, does this mean things not mentioned in the config file, and not mentioned in the code
can have an effect on the execution?
18:44 < Remi> Even if some of them are enabled by default, it's trivial to disable them
18:45 < Carlos> I disagree on the basis that an advanced programmer may want to have everything under control of code, not config file.
18:45 < Remco> on the carlos' latter statement: i think it will be mixed
18:45 < Carlos> Remco: yes. Some filters would be enabled by default.
18:45 < Remi> And if I just want to add *one* filter, I don't like writing _cpFilterList = cpg.defaultInputFilterList + [MyFilter()] + cpg.defaultOutputFilterList
18:45 < Remco> carlos, i don't think it would be obvious to newby's
18:46 < Remi> Carlos: Well, I guess they could always do "cpg.defaultFilterList = []"
18:46 < Carlos> Remi: there's a huge chance that, if you need to add a filter, it will not fall exactly in the middle of the list.
18:46 < Remco> remi, carlos: on the empty list thing. . . i have a suggestion
18:46 < Carlos> You know how sensitive the list is to the ordering.
18:47 < Carlos> Remi: now that's a good question. How can I put something in the 'before' or 'after' list? With your proposal I can't.
18:47 < Remco> _cpFilterList = None # no filter list at all
18:47 < Remco> _cpFilterList = [] # equal to not being available: inserted in the middle
18:47 < Carlos> Remco: good point too.
18:47 * Jos has to go pick up his son - good talking to you all. I'm interested to read the discussion of the extended HTTP verbs, from the log of this chat.
18:48 < Remco> bye jos!
18:48 < Carlos> Jos: thanks for coming!
18:48 < Remi> Well, let's have these 3 lists then (and people can change all of them). I still believe that (by far) most people won't need to tweak defaultInputFilterList and defaultOutputFilterList
18:48 < Jos> lhanks to you all
18:48 < Jos> l8r
18:48 < Remi> by jos
18:48 < Remco> remi: i agree
18:49 < Remi> so if they don't need to tweak them, they should have to use them ...
18:49 < Remco> but it should be possible. so if the list is constructed in the import statement, there's no problem
18:49 < Carlos> Remi: I agree.
18:49 < Carlos> At least with the lists proposal. They are members of the cpg structure, aren't they?
18:50 < Remco> but it would like to see all the filters be defined in the ini file. for clarity . how do you
tell a newbe: turn of that filter, while the newbe doesn't know it's enabled?
18:50 < Carlos> It would require all CP apps to have a INI file.
18:50 < Carlos> I don't think this should be a requirement.
18:50 < Remi> why would it require that ?
18:50 < Carlos> Unless...
18:51 < Carlos> Remi: if some filters are enabled by default, and if we take Remco's suggestion that the users should be able to see that they are enabled, where is he going to check it?
18:51 < Remi> that's the documentation's job !
18:52 < Carlos> I partly agree. I was only pointing out that Remco's comment made it a requirement.
18:52 < Carlos> (it was not my idea, mind you :-) but I see the point).
18:52 -!- gpciceri [~gpciceri@host112-35.pool80180.interbusiness.it] has left #cherrypy []
18:52 < Remco> true.
18:52 < Remco> :)
18:53 < Remi> why is it a requirement ? If you don't have a config file, you'll just use all the default values ...
18:53 < Remco> another question, that pops to my mind. where is the final list stored?
18:53 < Carlos> Remi: Remco wanted to have a simple place where users could turn on/off all default filters.
A standard config file can do it. BTW, that's what Apache does... it comes with a standard file, all commented.
18:53 < Carlos> But I agree, it should not be required.
18:53 < Remi> remco: there is not "final" list ... it's kept as 3 lists
18:54 < Remco> remi, ok
18:54 < Carlos> I guess we can ship a standard config file as a reference, and suggest that it should be used as a basis.
18:54 < Carlos> ok?
18:54 < Carlos> (suggest, not require)
18:54 < Remco> Carlos: in the dox, and as a file in the repo
18:54 < Remco> i agree
18:54 < Remi> eme too
18:54 < Remi> me too
18:55 < Remco> on the config settings per filter
18:55 < Remi> related question ...
18:55 < Carlos> We are getting quite good at agreeing :-)
18:55 < Carlos> Quite a progress considering the first few meetings ...
18:55 < Remco> carlos: we're all maturing ; )
18:56 < Remco> remi, you have a question? i have one as well. shoot
18:56 -!- peterhunt [~petaire@h0050dad12a7e.ne.client2.attbi.com] has joined #cherrypy
18:56 < peterhunt> hello
18:56 < Remco> hi
18:56 < Remi> hi peter
18:56 < peterhunt> how was your vacation remi?
18:56 < Carlos> Hi Peter. Nice to see you, well in time for the filter & aspect debate :-)
18:56 < Remi> remco: if yours is still on the same subject, go ahead ...
18:57 < peterhunt> is there an irc meeting today?
18:57 < Remco> thanks remi. it is
18:57 < Remi> peter: great :-) I love snowboarding !
18:57 < Carlos> Remi: before we move, can we sum up what we'd agreed to?
18:57 < peterhunt> Remi: whered you go?
18:57 < Remi> carlos: go ahead
18:57 < Remi> Peter: A small ski resort in the french alps
18:57 < peterhunt> ah, sounds fun
18:57 < Carlos> Remi: I'll need your help :-) But let's try.
18:57 < Remco> will a filter be notified of the settings, using some function, like filter.setConfig(key,value)
18:57 < Carlos> Ah. I thought about two ways.
18:58 < Carlos> setConfig is one...
18:58 -!- deelan [~chatzilla@ip-137-11.sn2.eutelia.it] has joined #cherrypy
18:58 < Carlos> but making configurable attributes properties is also good.
18:58 < Remco> hi deelan
18:58 < Carlos> A simple setattr can make it.
18:58 < peterhunt> hi deelan
18:58 < Carlos> Anyway.
18:58 < Carlos> We agreed that:
18:58 < Carlos> 1) the config file will be kept in the INI format (as it is today)
18:59 < Carlos> 2) sections will map to the cpg object hierarchy
18:59 < peterhunt> yay, no XML :)
18:59 < Remco> carlos: but that's for simple things, like setting a value, but making it a property should work as well then?
18:59 < peterhunt> Carlos: what do you mean about #2?
18:59 < Carlos> 3) attributes in the INI file will be mapped to attributes in the objects.
18:59 -!- deelan [~chatzilla@ip-137-11.sn2.eutelia.it] has left #cherrypy []
18:59 < Carlos> Remco: let's try :-) I assume it can be done, and it's more an coding question.
19:00 < Remco> carlos: ok
19:00 < Carlos> peterhunt: Wait a minute, I'll make an example out of it.
19:00 < Carlos> so, back to the list.
19:00 < Carlos> 1) the config file will be kept in the INI format (as it is today)
19:00 < Carlos> 2) sections will map to the cpg object hierarchy
19:00 < Carlos> 3) attributes in the INI file will be mapped to attributes in the objects.
19:00 < peterhunt> k
19:00 < Carlos> 4) Filters will be configurable as objects in the cpg hierarchy.
19:01 < Carlos> 5) filters will be declared in three lists: defaultInputFilterList, _cpFilterList, defaultOutputFilterList
19:02 < Carlos> 6) The final filterList is the concatenation: defaulInput + filterlist + defaultoutput.
19:02 < Carlos> Any of them can be overriden in code.
19:02 < Remco> on 6: it's kept seperated
19:02 < Remco> but for the program logic: it is :)
19:03 < Carlos> the standard _cpFilterList is empty, and the user can supply additional filters that will neatly fit in the middle of the chain.
19:03 < Carlos> 7) default filters are named, using the usual Python convention.
19:04 < Carlos> so: the default EncodingFilter can be acessed as the 'encodingFilter' attribute in the config file.
19:04 < Carlos> Config file sample:
19:04 < Remco> on 7: modulename.classname ?
19:04 < Carlos> No... filter name only, I think.
19:04 < peterhunt> can i put in an easy feature request?
19:04 < Carlos> Sample:
19:04 < Carlos> [root]
19:04 < Carlos> encodingFilter.encoding = latin1
19:04 < Carlos> encodingFilter is the name of the filter
19:04 < Carlos> encoding is an attribute of the encodingFilter
19:05 < Carlos> latin1 is a string, it's passed to the encoding attribute.
19:05 < Carlos> All type conversion is done by the attribute itself.
19:05 < Carlos> Ouch! That was a lot. Did i get it right?
19:05 < Remco> thnk so yes
19:05 < Carlos> Remi?
19:05 < Carlos> And Peter?
19:05 < Remi> great !
19:06 * peterhunt is confused but i have always had a weird take on filters anyway
19:06 < Remco> :]
19:06 < Carlos> Peter: what about the feature request?
19:06 < peterhunt> we ran into an issue with cherrypy config in subway
19:06 < peterhunt> ah yes abou tthat
19:06 < Carlos> oh.
19:06 < Remi> what about filters that come in 2 parts (ex: sessionInputFilter and sessionOutputFilter)... We should only have one set of config options ...
19:06 < peterhunt> do you know how configparser does interpolation?
19:06 < Carlos> No. I guess...
19:06 < peterhunt> %(myValue)s
19:06 < Remco> remi: why? they're 2 filters right?
19:07 < Carlos> Well. remi first, then peter.
19:07 < Remi> remco: yes, but only artificially because we need one at the beginning of the chaine and the other one at the end ...
19:07 < Carlos> For the cache filter (that works with two parts) I did all config in the first part, and the second filter just looks up on the first, as a 'slave'.
19:07 < Carlos> it should work most of the time.
19:08 < Carlos> Now, for Peter...
19:08 < Carlos> You would like to support interpolation on the config file?
19:08 < peterhunt> configparser already does
19:08 < peterhunt> but it would be nice to have a %(homeDirectory)s
19:08 < Carlos> What's the use case? Perhaps we can propose an alternative...
19:09 < Carlos> Well... Home dirs are *always* a problem.
19:09 < peterhunt> home dir would look something like: os.path.split(os.path.abspath(configFileName))[0]
19:09 < Carlos> As a matter of principle, I am opposed to advanced tricks with configuration. But that's only _me_.
19:09 < peterhunt> but subway is meant for stupid users who may run the script from the wrong working directory
19:10 < peterhunt> so it could mess up their staticContent
19:10 < Carlos> I'm confused...
19:10 < Carlos> You want:
19:10 < Carlos> 1) to *read* a user-defined config file and merge it with another one
19:10 < Carlos> 2) to allow variable substitution inside a config file?
19:10 < peterhunt> no
19:10 < peterhunt> 2) already exists in configparser
19:11 < peterhunt> i just want to be able to do:
19:11 < peterhunt> [staticContent]
19:11 < peterhunt> images=%(homeDirectory)s/images/
19:11 < Carlos> You do need it as a generic feature, or just because of home dirs?
19:11 < peterhunt> home dirs is the only application as of yet
19:12 < peterhunt> i have one other thing too
19:12 < Remco> proposal: use ~ for the user home dir, and ~~ for the config files home dir
19:12 < Carlos> I see... Remi & Remco, where does it fit in the discussion we had right now?
19:12 < peterhunt> could we set a "root" staticContent directory?
19:13 < Remi> well, that's a separate issue ...
19:13 < peterhunt> CP feels feature complete though
19:13 < Carlos> I like Remco's idea.
19:13 < Carlos> It solves Peter's problem, and does not go through loops to make a overgeneralization out of it.
19:14 < Remi> I think you need to define "homeDir" once in your config file and then re-use it later
19:14 < Carlos> Remi: ~ for home dir is usual.
19:14 * peterhunt afk
19:14 < peterhunt> ill be back
19:14 < Carlos> And even some calls in the Python std library use it.
19:15 < Remco> suggestion: ~ is the user home dir, ~~ is the script home dir. but you can override it using:
19:15 < Remco> [root]
19:15 < Remco> ~~ = <some value>
19:15 < Remco> where <some value> can make use of the non overwritten ~ and ~~
19:15 < peterhunt> i'll be intermittenly on and off
19:16 < Remco> this allows the user to redefine the home dir
19:16 < Remco> use his own home dir
19:16 < Carlos> os.path.expanduser already expands the ~
19:16 < Remi> but then would CP replace *all* occurences of "~" and "~~" ?
19:16 < Remco> not be bound to have his/her entire site fixed to one subtree
19:16 < Carlos> My proposal is to support *just* the ~ in a path.
19:16 < Carlos> ~~ --> -1.
19:17 < Remco> carlos, i disagree
19:17 < Remco> unix users would use ~ for their home dir, not a script dir
19:17 < Remi> People usually need ~~, not ~
19:17 < Remco> ~~ can be seen as a script/application/ini file home dir
19:17 < Carlos> ok.
19:17 < Remco> i would like to keep them both
19:17 < Carlos> But ~ is already supported by the library. ~~ is not.
19:17 < Remco> and still alow for aboslute filenames : )
19:18 < Remi> But then, each filter that reads a config option that is a path would have to do that substitution ...
19:18 < Carlos> What if we made all non-absolute paths count as relative to the config file?
19:18 < Remco> remi, or cp could do it for them
19:18 < Carlos> And not the current dir?
19:18 < peterhunt> carlos: what about third-party cfg values
19:18 < Remi> remco: but CP can't know which congif options are paths
19:18 < Carlos> So: when CP is started... it changes the dir to the dir where the cfg file is located. Wait - this can pose a problem with hosting providers... :-(
19:19 -!- gpciceri [~gpciceri@host112-35.pool80180.interbusiness.it] has joined #cherrypy
19:19 < Remco> remi, true, either we escape them using \if notwanted to expand, or we resort to carlos's sollution: all paths are relative tothe script. ~ is a user home dir, done by the filter, and absolute paths are absolute paths
19:20 < Remi> carlos: we can't do that ...
19:20 < Carlos> I see why.
19:21 < Remi> Let's move on to my next question ...
19:21 < Carlos> What's decided?
19:21 < Carlos> (before we move)
19:21 < Remi> nothing is (for now)
19:21 < Carlos> ok.
19:21 < Remco> ok
19:21 -!- Jos [~Jos@H192.C221.tor.velocet.net] has quit [Read error: Connection reset by peer]
19:22 < Remi> right now, there are 3 ways to pass the configuration to CP: pass a config filename, pass a dictionary or pass a ConfigParser object
19:22 < Remi> I'd like to consolidate that
19:22 < Carlos> sure.
19:22 < Remco> anyone willing to make sure we have a log. as jos wanted to read the log
19:22 < Carlos> I have it.
19:22 < Carlos> But I think that the additional verbs will have to wait for another meeting.
19:22 < Remco> remi: please, 'consolidate'?
19:22 < Remi> remco: have only one way of passing the configuration to CP
19:23 < Remco> remi, please, i now "import this" says you should. but i don't like config files :) i really love standalone code. .
19:23 < Remco> having the code and the ini file would be perfect for me
19:23 < Remco> furthermore, this also allows for dynamic behaviour. (for example the port used)
19:24 < Remco> this can't be done easily using a ini file
19:24 < Remco> </rant>
19:24 < Remco> remi, what do you think?
19:24 < Carlos> Remco: a dict-to-config wrapper would solve you problem?
19:24 < Carlos> as int:
19:24 < Carlos> as in:
19:25 < Carlos> cpg.server.start(Config({'port':8080}))
19:25 < Remi> carlos: I think it should be the opposite: we should always pass a dictionary and provide a config-to-dict function :-)
19:25 < Carlos> from cherrypy import ConfigDict
19:25 < Carlos> Humm...
19:25 < Remi> and it should be a dictionary of dictionaries, to map the config file structure
19:25 < Carlos> Good for me too.
19:25 < Remco> remi, i think you're right
19:25 < Remi> as in:
19:26 < Remi> {'server':
19:26 < Remi> {'socketPort': 8000}
19:26 < Remi> {'threadPool': 10}
19:26 < Remi> }
19:26 < Carlos> or: from cherrypy import ConfigFile
19:26 < Remi> Sorry ...
19:26 < Carlos> cpg.server.start(ConfigFile('defaultconfigfile.ini'))
19:26 < Carlos> Remi: I was only making an example.
19:26 < Remi> {'server': {'socketPort': 8000, 'threadPool': 10}, 'root': ...}
19:27 < Remco> this option seems fair to me!!
19:27 < Remco> both the dict in dicts, and the ConfigFile() usage
19:27 < Remi> cool
19:27 < Remi> so do we have a ticket ?
19:27 < Remco> it allows for code, _and_ the ini file : )
19:27 < Remi> carlos ?
19:28 < Carlos> We will have to evaluate if a ConfigParser wrapper can do it.
19:28 < Carlos> Remi: ok, but now that you raised it...
19:28 < Carlos> I would like to try to do a CherryPy sprint.
19:28 < Remi> wait ...
19:28 < Remi> There's a small pb ...
19:28 < Carlos> I have done a few with Remco.
19:28 < Carlos> What?
19:28 < Remi> Most people like to put their own config options in the config file ...
19:29 < Remi> they'll have to get them out of a dictionnary instead of a ConfigParser object ...
19:29 < Remi> I guess that's no big deal ...
19:29 < Almad> I agree
19:29 < Carlos> Well. That's a implementation detail that we can work out :-)
19:29 < Carlos> Again.
19:29 -!- services.oftc.net changed the topic of #cherrypy to: The not so official CherryPy channel ** Please read cherrypy.org, pythonweb.org, and use rafb.net/paste for code snippets
19:29 < Carlos> For the coding sprint.
19:30 < Carlos> I did some short sprints with Remco before, and it's very productive. It's something akin to ExtremeProgramming, but with remote pairs.
19:30 < Remco> and real fun!!
19:30 < Carlos> I would like to try such a sprint for some of the code that we have to do now...
19:30 < Remi> carlos: remotely ?
19:30 < Carlos> Yep.
19:30 < Remi> cool
19:30 < Carlos> We usually work by doing frequent checkins, and talking on IRC< or even Skype.
19:31 < Remi> how long is a session ?
19:31 < Carlos> So we're always 'pushing each other'.
19:31 < Carlos> Usually from a couple hours to 4 hours...
19:31 < Remi> cool
19:31 < Remco> then the timezone drama comes in : )
19:31 < Carlos> We get a lot of stuff done this way.
19:31 < Carlos> Ah.
19:31 < Remi> ouch
19:31 < Carlos> But for me & you european guys it's not a big deal.
19:32 < Remco> remi: either he want's lunch, or i want supper :)
19:32 < Carlos> I usually wake up early.
19:32 < Carlos> So we usually start by 700 (my local time) -> it's 900 for you, 1000 for Remco.
19:32 < Remi> I can do friday, saturday or sunday
19:32 < Carlos> Ok.
19:32 < Remco> remi, you want to make it a 'threesome'?
19:33 < Carlos> We got a good feel for it, and learned a lot on how to coordinate actions on IRC, SVN, and Trac.
19:33 < Remi> ok
19:33 < Remi> sounds good to me
19:33 < Carlos> ok.
19:33 < Remco> <ad>thank god for good trac support from python-hosting.com</ad> : )
19:33 < Carlos> The rules are quite simple indeed.
19:33 < MV> bye guys , i start having a timezone problem
19:33 < Carlos> Keep an eye on IRC, the other one on code.
19:33 < Remi> mv: bye
19:33 < Remco> by mv
19:33 < Carlos> MV, thanks for coming!
19:33 < Remco> cya!
19:34 -!- MV [~51c4fc2a@li8-222.members.linode.com] has left #cherrypy []
19:34 < Almad> do you think it's possible for newbie as me to look on those coding sprint? I'd like to just look/hear, just to learn
19:34 < Carlos> Ok.
19:34 < Remco> but we're getting OT here. .
19:34 < Remco> fine with me
19:34 < Carlos> We usually start with a ticket, and do it piece by piece. Each one may work on one part of it, or act as a reviewer.
19:35 < Carlos> Sometimes one does the coding, the other one tests.
19:35 < Carlos> ok?
19:35 < Remi> ok
19:35 < Carlos> When can we do it?
19:35 < Carlos> I can work on Friday or Saturday.
19:35 < Remco> but we have to set a date then. . and remi has a possibility this weekend. i know i don't have it on friday. . the weekend, depends on friday. (wheter i have met my deadline or not)
19:35 < Carlos> Sunday no, please.
19:35 < Carlos> :-)
19:35 < Remco> Carlos, not friday please, we have a project : /
19:35 < Carlos> Almad: feel free to come!
19:36 < Remi> so when will you know if you can do saturday ?
19:36 < Carlos> is saturday fine for you guys?
19:36 < Remco> friday night
19:36 < Almad> thanks!
19:36 < Carlos> Remco: depends more on you...
19:36 < Remi> not friday night ;-)
19:36 < Carlos> Friday night is not that good, I assume.
19:36 < Carlos> Saturday morning.
19:36 < Remco> no, then i will know if i can on saterday ; )
19:36 < Remi> not too early on Saturday please ;-)
19:36 < Carlos> :-(
19:37 < Carlos> What time is good for you Remi?
19:37 < Carlos> Remco: we also need CP stable, remember? :-)
19:37 < Remi> Saturday, anytime between 10am and 7pm GMT
19:37 < Remco> carlos: it's not your boss with a keyboard pointed at your head, remember : )
19:37 < Carlos> :-)
19:38 < Carlos> For all. Let's try to make it.
19:38 < Remco> on saterday in the day, remi's time. . i hope i can make it.
19:38 < Carlos> If we get a problem (any of us) we cancel it.
19:38 < Remco> it willbe the only optionthen i gues..
19:38 < Remco> more details by mail, on the cherrypy-devel list?
19:38 < Carlos> But at least we have a target, and we'll work to make it, ok:
19:38 < Carlos> Remi: 10am for you -> 8am for me. Fine. It can be one hour later though.
19:38 < Carlos> 11am for you, 9am for me.
19:39 < Carlos> We can do a ~2h sprint before you leave for lunch.
19:39 < Remi> ok
19:39 < Carlos> Remco: ok for you?
19:39 < Remco> checking. hold on please
19:39 < Carlos> Well.
19:39 < Carlos> Can we move on?
19:39 < Remi> Sure. I just created ticket #108
19:40 < Remco> 12 am for me that would be . . .fine i guess. . unless i get to know on friday i can't make it on saterday
19:40 < Remi> I guess we only need 2 people anyway ...
19:40 < Remco> well, i wanted to see what happens with three. seems marvelous to me : )
19:40 < Remi> (although 3 is better ...)
19:41 * peterhunt back for a second
19:41 < Carlos> Hi Peter.
19:41 < peterhunt> hi
19:41 < Remco> hi
19:41 < Carlos> Remi: can we open a ticket for Peter's request?
19:41 < Remi> sure, go ahead
19:41 < Remco> remi, carlos, Almad, let's try it
19:41 < Carlos> Even if still don't have a definitive solution...
19:42 < Almad> remi: well, i'm really not skilled, i'll just learn...
19:42 < Carlos> Peter: can you send a email to me with more info about the specific case? I'll try to check it over the weekend.
19:42 < peterhunt> do you guys need me for anything?
19:43 < Remco> fine with me :) we all had to at sometime. and about xp: i'm still learning as well
19:43 < Remi> peter: can you quickly summarize your proposal for improving filters/aspects ?
19:43 < Remi> The way I see it is:
19:43 < Remi> aspects are for methods
19:43 < Remi> filters are for requests
19:43 < Carlos> Also, if you can supply a good report of the substitution request, for home dirs, etc. so we can open the ticket and finish talking about it.
19:44 < Carlos> (sorry Remi. please move on)
19:44 < peterhunt> remi: okay, then lets make filters more powerful
19:44 < peterhunt> i.e. method return value
19:44 < Remi> what do you want to achieve that's hard to do now ?
19:45 < peterhunt> yield a dictionary and automatically stick it into a cheetah template and return the value of the processed template
19:45 < Remco> peterhunt, remi, carlos, if i may, i have an answer to peter
19:45 < Remco> assuming i am allowed? ; )
19:45 < Carlos> go on.
19:45 < Remi> sure
19:45 < Remco> peter, there is the xyaptu filter. this does something like that.
19:46 < Remco> you can use a structure like:
19:46 < Remco> def foo(self):
19:46 < Remco> yield someDict
19:46 < Remco> yield TemplateString
19:46 < Remco> the someDict is a 'Document Name Space', or, the dictionary used for variable substitution and inlne code in the template
19:47 < Remco> i've added some more advanced features to it, like subtemplate, filenames automatically extended and read etc
19:47 < peterhunt> theres no docs
19:47 < Remco> i can upload the latest version
19:47 < Remco> there is dox.
19:47 < Remco> XyaptuFilter if i'm not mistaken
19:47 < Remco> </rant>
19:47 < Remco> XyaptuFilter describes this
19:48 < Remco> in the latest version, it has a header and footer callback
19:48 < Remco> as well as a function to call for a base Document Name Space.
19:48 < Remco> allowing for internationalisation based on a sessionMap['lang'] value
19:48 < Remco> the header and footers are all tempaltes
19:48 < Remco> s/tempaltes/templates
19:49 < peterhunt> whats cpg.response.beforeBody
19:49 < Remco> it's something i've added, but removed in the last version.
19:49 -!- Jos [~Jos@216.138.221.192] has joined #cherrypy
19:49 < Remco> it's a xyaptufilter private request veriable
19:49 < peterhunt> ok
19:50 < Remco> but please, read these docs, check the source, and i will append the latest version to the wiki
19:50 < peterhunt> i am
19:50 < Remco> i would like to ask anyone to volunteer writing tests and/or docs. then it might be a nice builtin/core filter
19:50 < Remco> as it's pure python. . no dependencies
19:50 < Remco> </rant> again ;)
19:51 < Remco> remi, carlos, any suggestions?
19:51 * Remco is updating the attached file on the wiki page
19:51 < peterhunt> ok
19:52 < Remi> not really ... I just render my templates the regular way ...
19:52 < peterhunt> ah, may i interject a shameless plug for onering? :)
19:53 < Remco> don't know, but do it anyway ; )
19:53 < Carlos> onering?
19:53 < peterhunt> http://subway.python-hosting.com/wiki/OneRing
19:53 < peterhunt> i think it rocks :)
19:53 < peterhunt> i might add SSI includes into it but other than that it's feature complete
19:54 < peterhunt> essentially pymeld/htmltemplate and PSP
19:54 < Carlos> ok :-)
19:54 < Remi> ok
19:54 < peterhunt> with a really really cool fill() function to do nested layouts
19:54 < Remi> Pater: do you have more suggestions for filters ?
19:55 < Carlos> Peter: as much as I like Subway, I really think it would be better off by using other (lighter) templating system.
19:55 < peterhunt> docs
19:55 < Carlos> But that's OT, and thats (again __my opinion__) :-)
19:55 < peterhunt> Remi: for example, i'm looking at cpg.response api docs
19:55 < peterhunt> cpg.response.body, is that the return value of the method?
19:55 < peterhunt> iterable (list or generator) returning subsequent strings making the body of the response
19:56 < peterhunt> what if my method returns a generator? is this response.body?
19:56 < Remi> yes
19:56 < Carlos> Remi: doc-writing is a great thing to do in a sprint-like fashion. Each one write one page and reviews each others page... we can do it later.
19:56 < peterhunt> what if it returns a string? response.body = [returnValue]?
19:56 < Remi> yes
19:56 < Carlos> A string is automatically wrapped in a list.
19:56 < peterhunt> okay
19:57 < peterhunt> what if i return a dict or a tuple?
19:57 < Carlos> You shouldn't... unless a filter takes care of it.
19:57 < peterhunt> that's what i want to do
19:57 < Carlos> As the Xyaptu one does.
19:57 < peterhunt> xyaptu one _yields_ it
19:57 < Carlos> You can return anything you want.
19:57 < Carlos> Yes.
19:57 < peterhunt> will it be cpg.response.body, or wrapped in a list, or what?
19:58 < Carlos> But in principle, you can return anything you want to.
19:58 < Carlos> A string is wrapped in a list. We don't touch anything else.
19:58 < Remco> otherwise xmlrpc would be a goner
19:58 < Carlos> It is assumed, in this case, that the content is not valid HTML anyway, and will need to be processed by a filter.
19:59 * Remco has updated the wiki page, and attached the latest version
19:59 < Carlos> Good example - the xmlrpc filter accepts anything...
19:59 < peterhunt> Carlos: may i make a change to api docs?
19:59 < Carlos> Sure.
19:59 < peterhunt> k
19:59 < Carlos> But the API docs is Remi's work, not mine :-)))
20:00 < Remi> peter: sure, go ahead !
20:00 < Carlos> But it's in the Wiki, its there to be edited too :-)
20:00 < Remi> it's a wiki ;-)
20:00 < Carlos> As long as you don't spray 'Subway rulez' all over the place it's fine :-)
20:00 < peterhunt> http://www.cherrypy.org/wiki/CpgResponse
20:00 < peterhunt> is that adequate?
20:01 < Remco> we have the delete by ip function now carlos : )
20:01 < peterhunt> Carlos: i won't
20:02 < Carlos> ok.
20:02 < Remco> peter, basically it is. . untill someone writes more details
20:02 < Carlos> Peter: never mind, I was just joking.
20:02 < Remco> i think there should be a fine tutorial, like carlos has written, on writing filters
20:02 < Carlos> We seem to be a quite good mood around here today :-)
20:02 < Remi> yep ... I just added a ticket for that
20:03 < Remi> for the tutorial, not for being in a good mood :-)
20:03 < Remco> :]
20:03 -!- gpciceri [~gpciceri@host112-35.pool80180.interbusiness.it] has quit [Quit: gpciceri]
20:03 < Remi> it's getting a bit late for talking about verbs ...
20:03 < Carlos> I see...
20:03 < Remi> I think we'll save that for later
20:04 < Remco> guess so
20:04 < Remco> still have to do some work
20:04 < Carlos> Can we have another meeting next week? I'm tired today, travelled overnight, and I really miss a real bed :-(
20:04 < Remi> you mean this week-end ? or the following one ?
20:04 < Remi> sorry, "next week" !
20:04 < Carlos> Over the next week...
20:05 < Remi> Great example of my brain playing tricks on me ... I read "next week-end" :-)
20:05 < Remi> Sure, we'll have another one next week
20:05 < Carlos> I'm devising a good plan for we to work on the configuration on *this* weekend.
20:06 < Remi> Well, I'll work on CP on friday so I may get to this ...
20:06 < peterhunt> i don't see much wrong with the config files
20:06 < Remi> or maybe I'll just fix bugs
20:06 < Remco> there are enough tickets to take care of
20:07 < Remi> yup
20:07 < Carlos> peterhunt: I'm sure that after our improvements are done, it will be even better :-)
20:07 < Remi> Alright, are we all set ?
20:07 < Carlos> ok.
20:07 < Remco> guess so. .
20:07 < Remi> Any last words ?
20:07 < peterhunt> just trying trying to lessen the load
20:08 < Carlos> Next meeting, on IRC, saturday morning.
20:08 < peterhunt> Remi: keep it simple! :)
20:08 < Remi> ok
20:08 < Remco> lastwords: goodnight everyone : ))
20:08 < Remi> peter: don't worry, I will :-)
20:08 < Remi> my brain can't handle complicated anyway ;-)
20:08 < Remi> good nite
20:08 < Remco> hahahaha
20:08 < Carlos> peter: I can say in publicy that Remi is responsible for making *me* want to make things simpler.
20:08 < Carlos> That's a compliment, Remi!
20:08 < Remco> fmi: saterday morning, is 11.00 am gmt?
20:09 < Carlos> ok.
20:09 < Remi> carlos: :-)
20:09 < Remi> ok
20:09 < Remi> good nite
20:09 < Remi> bye
20:09 < Remco> bye
20:09 < Carlos> See you all then.
20:09 < Remi> Carlos: can you put the logs in the wiki ?
20:09 < Carlos> Yep.
20:09 < Remi> thanks. bye
20:09 < Carlos> Is there anything to edit?
20:09 < Carlos> Besides a few bad jokes?
20:09 < Remco> :)
20:09 < Remi> I think it's fine
20:10 < Carlos> ok.
20:10 < Remi> bye
20:10 < Carlos> The actual part where I summed up the situation on config & filters...
20:10 < Carlos> It will be split & made into a ticket.
20:10 < Remi> ok
20:10 < Carlos> Ah, and Peter, please, I want to open a ticket for the home dir stuff.
20:10 < Remi> nite
20:10 < Almad> bye
20:10 -!- Remi [user@host81-155-146-29.range81-155.btcentralplus.com] has left #cherrypy []
