MoinMoin: MoinMoinChat/Logs/moin-dev/2008-04-12

2008-04-12T00:17:35  <zenhase> xorAxAx: are you there?
2008-04-12T00:17:41  <xorAxAx> yes
2008-04-12T00:18:21  <zenhase> i am looking on the featurerequest and also request-code again
2008-04-12T00:18:59  <xorAxAx> yeah
2008-04-12T00:19:00  <zenhase> i was a bit wondering about this part 'TODO: Code'
2008-04-12T00:19:07  <xorAxAx> where is that? :)
2008-04-12T00:19:42  <zenhase> right beneath 'Basics of Moin as a WSGI application'
2008-04-12T00:20:25  <zenhase> 'moin already supports wsgi, so for the code it is primarily testing what is needed'
2008-04-12T00:21:53  <xorAxAx> yes. you correctly realised that refactoring is a nice goal as well
2008-04-12T00:21:55  <zenhase> since it's meant as quite some refactoring it isn't about tests only anymore
2008-04-12T00:22:21  <xorAxAx> but basically, ripping out some code and wrapping stuff over it is fine as well
2008-04-12T00:22:27  <xorAxAx> not for you, though
2008-04-12T00:22:27  <zenhase> what i was thinking about is:
2008-04-12T00:22:35  <xorAxAx> otherwise you were already finished after a week :)
2008-04-12T00:22:37  <zenhase> how to structure this rewrite
2008-04-12T00:22:48  <zenhase> yeah ofcourse :)
2008-04-12T00:23:38  <zenhase> the way i figure, request.run() becomes a (or perhaps multiple middleware-layered) wsgiapps
2008-04-12T00:24:00  <zenhase> and the request-object is something new, based on the wsgi environ
2008-04-12T00:24:19  <xorAxAx> yes, it doesnt need to be fancy
2008-04-12T00:24:21  <zenhase> i saw this short discussion in #moin with mitsuhiko
2008-04-12T00:24:40  <zenhase> where things like paste or webob against werkzeug were mentioned
2008-04-12T00:24:52  <xorAxAx> maybe mitsuhiko wants to join in here? :)
2008-04-12T00:25:42  <zenhase> meanwhile i will get the current werkzeug-trunk
2008-04-12T00:25:51  <zenhase> paste i got already
2008-04-12T00:26:24  * mitsuhiko reads the backlog
2008-04-12T00:29:04  <zenhase> not that much backlog right now :)
2008-04-12T00:29:16  <zenhase> ok, perhaps the stuff from some hours ago
2008-04-12T00:33:58  <zenhase> if the current API on request should stay the same, so one doesn't has to touch other parts of moin, the request-object will have to be custom-written anyway
2008-04-12T00:34:39  <zenhase> it starts with having no distinction between request/response objects right now
2008-04-12T00:35:39  <zenhase> but of course the ways params are parsed and accessed can be inspired by either webob or werkzeug
2008-04-12T00:36:21  <mitsuhiko> zenhase: i think moin should depend on one of those libraries rather then reinventing the wheel
2008-04-12T00:36:44  <mitsuhiko> you can still provide a "kitchen sink" version of moin that ships those libraries
2008-04-12T00:36:57  <zenhase> mitsuhiko: yeah
2008-04-12T00:37:23  <mitsuhiko> .oO( and of course i recommend werkzeug ;-) )
2008-04-12T00:37:26  <zenhase> i am a strong advocate of using external libs
2008-04-12T00:37:39  <zenhase> since it relieves of the maintenance of code
2008-04-12T00:38:31  <zenhase> but going from request-only to request/response will have some impact
2008-04-12T00:39:05  <zenhase> ok, perhaps you can wrap this up in a combined class somehow ...
2008-04-12T00:39:18  <mitsuhiko> zenhase: you can configure werkzeug in a way that you can be api compatible with the old request class
2008-04-12T00:39:23  <mitsuhiko> (if that's a good idea, i don't know)
2008-04-12T00:39:48  <zenhase> hmm ok
2008-04-12T00:39:51  <mitsuhiko> all the werkzeug functionality is available on extra functions additionally to the request/response objects it's shipping
2008-04-12T00:39:52  <zenhase> btw.
2008-04-12T00:40:12  <zenhase> before webob i would have opted in favour of werkzeug
2008-04-12T00:40:35  <zenhase> but right now, since webob isn't as big as whole paste, i am quite fond of webob again :)
2008-04-12T00:40:57  <mitsuhiko> i think werkzeug has quite a few unique advantages over webob
2008-04-12T00:41:09  <zenhase> they have all those nifty parsers in place
2008-04-12T00:41:16  <mitsuhiko> zenhase: which?
2008-04-12T00:41:39  <zenhase> for accept-headers, date-headers, in general conversion for parsable headers
2008-04-12T00:41:48  <mitsuhiko> zenhase: so does werkzeug
2008-04-12T00:41:52  <mitsuhiko> and werkzeug works both ways
2008-04-12T00:42:38  <zenhase> hmm
2008-04-12T00:42:42  <mitsuhiko> zenhase: http://paste.pocoo.org/show/39689/
2008-04-12T00:42:48  <zenhase> wait did i miss that one?
2008-04-12T00:43:45  <mitsuhiko> regarding http header parsing werkzeug pretty much covers all of time with a few less common exceptions
2008-04-12T00:44:12  <mitsuhiko> we're not providing if-range support as it's uncommon for dynamic applications to operate on those headers
2008-04-12T00:44:18  <zenhase> hmm
2008-04-12T00:44:35  <zenhase> what about accept? i only see that you return the header here from the request-property
2008-04-12T00:45:22  <zenhase> ah damnit
2008-04-12T00:45:29  <zenhase> forget about that one ;)
2008-04-12T00:45:41  <mitsuhiko> zenhase: should there be anything missing in terms of http header parsing i would love to hear about that :)
2008-04-12T00:45:44  <zenhase> i just didn't see it right away
2008-04-12T00:46:13  <zenhase> disregard my musings ;)
2008-04-12T00:46:19  <mitsuhiko> zenhase: you can even parse http authorization and www-authenticate headers :)
2008-04-12T00:46:59  <zenhase> yeah, saw the mixins now
2008-04-12T00:47:10  <zenhase> and that they use the parse-functions :o
2008-04-12T00:47:14  <zenhase> *whistles*
2008-04-12T00:47:48  <mitsuhiko> the parse function saved my ass multiple times as django has no parsing support at all
2008-04-12T00:48:10  <mitsuhiko> so i can use werkzeug with other libraries without having to replace their request objects with werkzeug's
2008-04-12T00:48:30  <zenhase> yeah
2008-04-12T00:48:36  <mitsuhiko> anyways. i'm not forcing yout o use werkzeug. just saying that we do header parsing :)
2008-04-12T00:48:51  <zenhase> yeah ok
2008-04-12T00:50:02  <zenhase> also it would provide also some general wsgi tools
2008-04-12T00:50:10  <zenhase> -also+too
2008-04-12T00:50:26  <zenhase> which webob does not ... webob is request/response only right now
2008-04-12T00:50:47  <zenhase> werkzeug has routing
2008-04-12T00:50:57  <mitsuhiko> (which however is not useful for a wiki)
2008-04-12T00:50:57  <zenhase> and the exception-stuff
2008-04-12T00:51:14  <zenhase> not really, that's perhaps right :)
2008-04-12T00:51:53  <zenhase> the static-stuff can be satisfied by a simple path_info.startswith('/moinstatic170') or sth. like that
2008-04-12T00:52:01  <zenhase> no complex routing necessary ;)
2008-04-12T00:53:32  <mitsuhiko> zenhase: werkzeug has basic testing support too
2008-04-12T00:53:39  <mitsuhiko> which could be useful
2008-04-12T00:53:49  <zenhase> yeah
2008-04-12T00:54:03  <mitsuhiko> especially if the CLIRequest should still exist
2008-04-12T00:54:31  <zenhase> i think it should
2008-04-12T00:54:47  <zenhase> well, in some form at least
2008-04-12T00:55:13  <zenhase> commandline scriptable wikis are awesome ;)
2008-04-12T00:55:52  <zenhase> so as i see it, werkzeug has quite many interesting features to it, which would be useful
2008-04-12T00:56:07  <zenhase> and this in 10k lines with contribs
2008-04-12T00:56:38  <mitsuhiko> it will become a bit slimmer soon i think
2008-04-12T00:56:47  <mitsuhiko> there is some refactoring going on currently
2008-04-12T00:57:40  <zenhase> hmm
2008-04-12T00:57:57  <zenhase> ok, just made a comparison
2008-04-12T00:58:43  <zenhase> webob + weberror (which gives quite much the same functionality) is just below 10k locs
2008-04-12T00:59:04  <zenhase> (ok didn't compare comments, but they seem to be both documented quite extensive)
2008-04-12T00:59:44  <zenhase> what i like about webob btw. is how request is just a lightweight proxy to environ
2008-04-12T00:59:56  <zenhase> it's like completely stateless
2008-04-12T00:59:59  <zenhase> just a facade
2008-04-12T01:00:28  <mitsuhiko> just that it's no real advantage
2008-04-12T01:00:31  <zenhase> dunno if this is relevant for moin though, you don't have to recreate request from environ very often
2008-04-12T01:00:39  <mitsuhiko> as it consumes the input stream and no other library can use it later on
2008-04-12T01:00:41  <zenhase> actually never ;)
2008-04-12T01:00:58  <mitsuhiko> the disadvantage of it is that you can end up in situations with weird behavior
2008-04-12T01:01:02  <mitsuhiko> especially unicode wise
2008-04-12T01:01:49  <mitsuhiko> i think it's not the best idea to provide a bytestring and unicode interface to the same data
2008-04-12T01:02:31  <zenhase> hmm?
2008-04-12T01:02:43  <zenhase> what do you mean? the str_POST and POST stuff?
2008-04-12T01:02:51  <zenhase> with the UnicodeMultidict wrappers?
2008-04-12T01:03:23  <mitsuhiko> yes
2008-04-12T01:03:58  <zenhase> hmm
2008-04-12T01:04:09  <zenhase> regarding the consumation of the inputstream
2008-04-12T01:04:17  <zenhase> is this a problem?
2008-04-12T01:04:44  <zenhase> if it's a POST with multipart/formdata, the stream isn't that interesting
2008-04-12T01:04:52  <mitsuhiko> na, that's perfectly okay
2008-04-12T01:04:57  <zenhase> after it's parsed, you can access the post-vars
2008-04-12T01:05:01  <mitsuhiko> the problem is: what happens on request reattaching :)
2008-04-12T01:05:16  <mitsuhiko> webob stores the parsed data as paste.parsed_form_data in the wsgi environment
2008-04-12T01:05:26  <zenhase> yes
2008-04-12T01:05:32  <mitsuhiko> it's true that that way they can reattach the request object in a middleware and will get the same data back
2008-04-12T01:05:32  <zenhase> so you just get that
2008-04-12T01:05:34  <zenhase> it's a proxy
2008-04-12T01:05:37  <mitsuhiko> however the encoding might be different
2008-04-12T01:05:44  <zenhase> well
2008-04-12T01:05:47  <zenhase> but that's no problem
2008-04-12T01:05:54  <zenhase> because encoding is done on the fly
2008-04-12T01:05:57  <mitsuhiko> so what they achieved was abusing the wsgi environment for their own purpose by locking out other libraries
2008-04-12T01:06:02  <zenhase> the unicodemultidict decodes
2008-04-12T01:06:09  <zenhase> not the process of parsing the wars
2008-04-12T01:06:10  <zenhase> vars
2008-04-12T01:06:23  <mitsuhiko> zenhase: yes. that's the problem
2008-04-12T01:06:32  <mitsuhiko> they should be doing it at parsetime
2008-04-12T01:06:41  <zenhase> uh
2008-04-12T01:07:00  <zenhase> why are they locking out other libraries?
2008-04-12T01:07:02  <mitsuhiko> well. anyways. just don't use pastes/webobs/werkzeug's request objects in middlewares and you're fine
2008-04-12T01:07:23  <mitsuhiko> zenhase: because middlewares that use the request objects of paste consume the data there
2008-04-12T01:07:39  <mitsuhiko> so in the end they are django, just worse
2008-04-12T01:08:06  <zenhase> you mean if other parts don't want to use webob, they are doomed?
2008-04-12T01:08:06  <mitsuhiko> django at least moved that sort of request processing out of the wsgi layer to not annoy other libraries
2008-04-12T01:08:37  <mitsuhiko> zenhase: well. if there is a middleware you want to use that uses webob and you are using werkzeug, werkzeug won't be getting form data after consumption
2008-04-12T01:08:59  <mitsuhiko> and they are causing problems in their own ecosystem that way too
2008-04-12T01:09:06  <mitsuhiko> which is a shame
2008-04-12T01:09:17  <zenhase> if you have any middleware, that does some sort of processing of the input stream, werkzeug will perhaps get problems if it sits on the end
2008-04-12T01:09:27  <mitsuhiko> that "attaching requests to environments" was just a design mistake
2008-04-12T01:09:47  <mitsuhiko> zenhase: the same happens if i use a werkzeug request in the middleware and webob tries to consume the stream later on
2008-04-12T01:09:54  <mitsuhiko> that just can't work
2008-04-12T01:10:05  <mitsuhiko> and that's the reason why so many people say "middlewares considered harmful"
2008-04-12T01:10:06  <zenhase> so it's a common problem again
2008-04-12T01:10:34  <mitsuhiko> zenhase: yes. but paste/webob advertise using those libs for middleware development
2008-04-12T01:10:53  <zenhase> well, i still think that this 'middlewares considered harmful'-thinking is based on a fantasy about how composing of webapps works
2008-04-12T01:11:16  <mitsuhiko> wsgi middlewares where designed for a different purpose
2008-04-12T01:11:37  <mitsuhiko> there are useful middlewars: error handlers, static data injectors, profilers etc.
2008-04-12T01:11:49  <mitsuhiko> but putting application logic into a middleware just is wrong
2008-04-12T01:11:54  <mitsuhiko> for so many reasons
2008-04-12T01:12:44  <zenhase> what application logic?
2008-04-12T01:13:21  <zenhase> the problem people have, is when middlewares are somehow dependant on their arrangement in the wsgi stack
2008-04-12T01:13:36  <ThomasWaldmann> mitsuhiko: btw, how does wsgi/werkzeug handle file uploads? are they first kept in memory completely?
2008-04-12T01:13:46  <zenhase> that something way up higher requires something down there
2008-04-12T01:13:56  <mitsuhiko> ThomasWaldmann: you can configure it to keep it in memory, by default it uses a temporary file
2008-04-12T01:14:13  <mitsuhiko> zenhase: if your application depends on a middleware in production usage you have problem
2008-04-12T01:14:22  <mitsuhiko> it's as simple as that :)
2008-04-12T01:14:23  <zenhase> mitsuhiko: no i don't
2008-04-12T01:14:40  <zenhase> mitsuhiko: thing is ... that is how they build frameworks like pylons
2008-04-12T01:14:44  <mitsuhiko> zenhase: but that's the definition of wsgi middlewares
2008-04-12T01:14:51  <zenhase> to them it's just library code
2008-04-12T01:14:56  <mitsuhiko> zenhase: no. pylons does not depend on middlewares
2008-04-12T01:14:57  <zenhase> but they depend on those libraries
2008-04-12T01:15:00  <ThomasWaldmann> mitsuhiko: ah, sounds good :)
2008-04-12T01:15:11  <mitsuhiko> at least not beyond what environment.py does
2008-04-12T01:15:22  <zenhase> well, so?
2008-04-12T01:15:23  <mitsuhiko> they did on the past and it changed which is good
2008-04-12T01:15:34  <zenhase> they do depend on some
2008-04-12T01:15:46  <zenhase> even if it's only a small set
2008-04-12T01:15:50  <mitsuhiko> zenhase: middlewares applied inside the application are fine
2008-04-12T01:15:51  <zenhase> in environment.py
2008-04-12T01:16:06  <zenhase> well, we are talking about an application
2008-04-12T01:16:08  <mitsuhiko> you can use the wsgi protocol inside your application too if you're masochist
2008-04-12T01:16:11  <zenhase> which applies middlewares
2008-04-12T01:16:27  <mitsuhiko> zenhase: i'm talking about exchangeable middlewares that provide addon functionality
2008-04-12T01:16:35  <mitsuhiko> like a middleware that adds session support
2008-04-12T01:16:37  <zenhase> mitsuhiko: i don't do
2008-04-12T01:16:43  <mitsuhiko> or a midddleware that does authentication
2008-04-12T01:16:47  <zenhase> i am talking about composing an application
2008-04-12T01:16:51  <mitsuhiko> both of which are flawed by design
2008-04-12T01:17:05  <mitsuhiko> as they *need* a rough understanding of the application to work properly
2008-04-12T01:17:11  <mitsuhiko> the auth for example would have to talk to the database
2008-04-12T01:17:14  <zenhase> or other way round
2008-04-12T01:17:22  <zenhase> app needs understanding about them and adapt
2008-04-12T01:17:34  <mitsuhiko> zenhase: look at authkit and you can see how it failed
2008-04-12T01:17:51  <zenhase> authkit looks quite bad yes
2008-04-12T01:18:04  <mitsuhiko> beaker makes more fun as non middleware too
2008-04-12T01:18:12  <zenhase> but doesn't mean you should not consider putting moin auth in a middleware
2008-04-12T01:18:20  <mitsuhiko> zenhase: well yes it means
2008-04-12T01:18:31  <mitsuhiko> there is no reason to put moin auth into a *wsgi* middleware
2008-04-12T01:18:39  <mitsuhiko> middlewares don't work in two directions
2008-04-12T01:18:41  <mitsuhiko> auth has to do
2008-04-12T01:18:57  <mitsuhiko> by abusing the environment as reverse communication channel you're abusing wsgi
2008-04-12T01:19:05  <zenhase> reverse?
2008-04-12T01:19:12  <mitsuhiko> (and btw, that's not only my opinion but only the opinion of the inventor of that thing)
2008-04-12T01:19:37  <zenhase> why is this a reverse communication?
2008-04-12T01:19:43  <mitsuhiko> zenhase: the environment is used as communication channel for wsgi components
2008-04-12T01:19:47  <mitsuhiko> at least in pasteland
2008-04-12T01:19:52  <zenhase> you promote established identity
2008-04-12T01:19:59  <zenhase> upwards to the application
2008-04-12T01:20:26  <mitsuhiko> zenhase: imagine the following situation
2008-04-12T01:20:32  <mitsuhiko> you have an application that does database stuff
2008-04-12T01:20:37  <mitsuhiko> where does it set up the database connection?
2008-04-12T01:20:45  <mitsuhiko> in the constructor
2008-04-12T01:20:51  <mitsuhiko> it has to forward the database connection to the middleware
2008-04-12T01:20:54  <mitsuhiko> it does that via environment
2008-04-12T01:21:04  <zenhase> hmm
2008-04-12T01:21:07  <mitsuhiko> that's how things (unfortunately) work currently for quite a few pylons applications
2008-04-12T01:21:16  <mitsuhiko> and the wsgi environment is not meant to do that
2008-04-12T01:21:21  <mitsuhiko> it's also very complicated
2008-04-12T01:21:27  <zenhase> never thought about passing it down
2008-04-12T01:21:30  <zenhase> this way
2008-04-12T01:21:40  <mitsuhiko> it's a lot simpler just using the request object internally and just doing everything inside the applications
2008-04-12T01:21:48  <zenhase> also pylons makes heavy use of thread local objects ;)
2008-04-12T01:22:20  <xorAxAx> and one char names
2008-04-12T01:22:36  <zenhase> yeah, those too ;)
2008-04-12T01:22:40  <mitsuhiko> zenhase: have you seen how django middlewares work?
2008-04-12T01:22:55  <mitsuhiko> that's the kind of approach i promote for webob/paste/werkzeug applications too
2008-04-12T01:23:01  <zenhase> no, django is a framework i didn't look at closely
2008-04-12T01:23:13  <zenhase> perhaps i should take a look
2008-04-12T01:23:35  <mitsuhiko> and tell library writers to provide a normal class/function interface to their stuff and not relying on a wsgi middleware
2008-04-12T01:23:43  <zenhase> ok, then let's cut the middleware-ranting :)
2008-04-12T01:23:51  <mitsuhiko> yep :)
2008-04-12T01:24:05  <mitsuhiko> that's actually a very good idea as my clock shows 1:23
2008-04-12T01:24:11  <zenhase> no request-objects recreatable from the environment
2008-04-12T01:24:24  <zenhase> since it won't be crucial for moin anyway
2008-04-12T01:24:34  <mitsuhiko> zenhase: you can make werkzeug recreates it's request too
2008-04-12T01:24:44  <mitsuhiko> that's a oneliner if you want it :)
2008-04-12T01:24:51  <zenhase> well, just save the body in advance?
2008-04-12T01:24:51  <mitsuhiko> i just don't think it's a good idea ^^
2008-04-12T01:24:58  <zenhase> well ok :)
2008-04-12T01:25:17  <mitsuhiko> zenhase: the biggest problem moin will have on the wsgi path is this one:
2008-04-12T01:25:24  <mitsuhiko> wsgi works the other way round
2008-04-12T01:25:36  <zenhase> 'the other way round'?
2008-04-12T01:25:42  <mitsuhiko> in moin you do request.write("foo") and it actually writes foo to the webserver
2008-04-12T01:25:50  <zenhase> yes
2008-04-12T01:25:54  <mitsuhiko> in wsgi you have to do yield "foo"
2008-04-12T01:25:58  <mitsuhiko> (well, not exactly)
2008-04-12T01:26:02  <mitsuhiko> yield is write + flush
2008-04-12T01:26:21  <zenhase> right now you can write with the callable start_response returns ;)
2008-04-12T01:26:30  <mitsuhiko> there are ways to convert such request.write into a generator (werkzeug.contrib.iterio for example) but that requires greenlet support
2008-04-12T01:26:39  <zenhase> but i know, ian bicking himself isn't fond of that part of the spec
2008-04-12T01:26:45  <mitsuhiko> zenhase: yes, but then you can't use middlewares
2008-04-12T01:26:49  <mitsuhiko> and it's unsupported with wsgi2
2008-04-12T01:26:59  <zenhase> yes
2008-04-12T01:27:05  <zenhase> which is totally ok
2008-04-12T01:27:14  <mitsuhiko> the general approach for wsgi is: buffer internally, yield one chunk
2008-04-12T01:27:22  <zenhase> i didn't like the start_response ever :)
2008-04-12T01:27:27  <mitsuhiko> unless you have huge amount of data, that's the way to go
2008-04-12T01:27:28  <zenhase> yep
2008-04-12T01:27:55  <zenhase> and the caching stuff, ThomasWaldmann was afraid about (like having content-length)
2008-04-12T01:28:01  <mitsuhiko> the switch to wsgi will most likely will mean that the work on the template engine integration would have to be picked up again
2008-04-12T01:28:17  <zenhase> this can be done by getting everything from the app in some caching layer middleware
2008-04-12T01:28:24  <zenhase> yes
2008-04-12T01:28:26  <zenhase> well
2008-04-12T01:28:31  <mitsuhiko> because currently the way the response is send is ridiculously and blocked the template engine tries :)
2008-04-12T01:28:35  <zenhase> this would need send_page too
2008-04-12T01:28:35  <mitsuhiko> at least mine :)
2008-04-12T01:28:48  <zenhase> it's not request.write alone
2008-04-12T01:29:14  <zenhase> but yes, getting rid of writing to the request directly will greatly simplify things
2008-04-12T01:29:34  <zenhase> but as you may have noticed, this is quite a big effort ;)
2008-04-12T01:29:46  <mitsuhiko> it is :(
2008-04-12T01:30:01  <zenhase> as i see it, it requires refactoring of send_page and parser/formatter
2008-04-12T01:30:17  <mitsuhiko> .oO( that's the advantage of not abstracting code )
2008-04-12T01:30:20  <zenhase> additionally to the lower request layer
2008-04-12T01:30:32  <mitsuhiko> the fact that formatters and parsers write directly to the request is awkward
2008-04-12T01:30:36  <zenhase> well, there are some abstractions visible ;)
2008-04-12T01:30:57  <mitsuhiko> wsgi + dom devs have to team up at that point
2008-04-12T01:30:58  <zenhase> i think the fact that formatters/parsers are intermingled with each other is another one ;D
2008-04-12T01:31:02  <zenhase> yep
2008-04-12T01:31:51  <zenhase> btw, don't get to excited about the wsgi stuff ... as i understood xorAxAx the send_page proposal rates higher from his point of view
2008-04-12T01:31:58  <zenhase> though this all is somehow connected
2008-04-12T01:32:10  <mitsuhiko> xorAxAx: btw. you haven't given points so far
2008-04-12T01:32:13  <zenhase> one will ease the refactoring of the other
2008-04-12T01:32:57  <zenhase> and i think if i should start with either one of those, the other will follow later on
2008-04-12T01:41:45  <xorAxAx> zenhase: no, i didnt say that
2008-04-12T01:41:52  <xorAxAx> mitsuhiko: to whom?
2008-04-12T01:42:26  <xorAxAx> anyway, good night
2008-04-12T01:42:28  * xorAxAx &
2008-04-12T01:43:00  <zenhase> xorAxAx: ok, got something wrong then
2008-04-12T01:43:05  <zenhase> gn8 xorAxAx
2008-04-12T01:46:37  <zenhase> i need a brighter display for my laptop
2008-04-12T01:46:53  <zenhase> i can't see anything in my builtin webcam
2008-04-12T01:59:35  <fgs> bbl
2008-04-12T10:29:39  <xorAxAx> "We are targeting Wednesday as the date to give you your final student
2008-04-12T10:29:40  <xorAxAx> allocations. "
2008-04-12T10:36:23  <zenhase> moin
2008-04-12T10:40:39  <xorAxAx> moin florian
2008-04-12T10:43:44  <zenhase> moin alexander
2008-04-12T11:00:24  <kikka> moin
2008-04-12T12:06:15  <ThomasWaldmann> moin
2008-04-12T12:11:38  <ThomasWaldmann> TheSheep: xorAxAx: you didnt request mentorship for any projects yet
2008-04-12T12:12:38  <ThomasWaldmann> also, every mentor who did not score yet, please do ASAP, see xorAxAx' comment a few lines above
2008-04-12T12:13:25  * ThomasWaldmann did some preliminary mentor assignments
2008-04-12T12:15:56  <ThomasWaldmann> btw, scoring should not depend on current rank of a project. so please score ALL projects.
2008-04-12T12:16:18  <ThomasWaldmann> (of course, if you don't care at all for a project, the score can be 0)
2008-04-12T12:18:27  <ThomasWaldmann> also, you may request mentorship of a project, even if mentorship has already been assigned to / requested by somebody else
2008-04-12T14:04:10  <dennda> xorAxAx: F5 :)
2008-04-12T14:05:12  <xorAxAx> ok :)
2008-04-12T14:11:03  <xorAxAx> ThomasWaldmann: TheSheep is currently busy with rupy
2008-04-12T14:12:01  <ThomasWaldmann> ah, right :)
2008-04-12T14:14:11  <ThomasWaldmann> let's hope he has recovered until tuesday :)
2008-04-12T14:16:05  <ThomasWaldmann> moon rising :P
2008-04-12T14:17:13  <waldi> werewolf?
2008-04-12T14:18:09  * ThomasWaldmann .oO(that was a mentor-only joke :)
2008-04-12T14:18:48  <ThomasWaldmann> waldi: any news about usable xml libs?
2008-04-12T14:18:58  <xorAxAx> lol
2008-04-12T14:23:22  <johill> ThomasWaldmann: see my reply, but I have to run
2008-04-12T14:23:57  <dennda> xorAxAx: what do you think?
2008-04-12T14:24:05  <xorAxAx> dennda: looks good
2008-04-12T14:24:47  <dennda> xorAxAx: ok. I was a bit afraid you may have gotten that wrong :)
2008-04-12T14:25:00  * dennda challenges the router
2008-04-12T14:38:44  * dennda lost
2008-04-12T14:50:29  <ThomasWaldmann> dreimark still seems to have dsl trouble
2008-04-12T14:52:45  * xorAxAx increased the stability of his dsl connection yesterday by several magnitudes - before it was always resyncing when i put forth my feet
2008-04-12T14:52:57  <dennda> How?
2008-04-12T14:54:01  <xorAxAx> i just dismantled the baffle of the TAE socket because its slit was too small for the plug
2008-04-12T14:54:23  <dennda> lol
2008-04-12T14:54:59  <xorAxAx> before, i didnt see that it didnt really fit
2008-04-12T15:26:50  * ThomasWaldmann writes page acl tests
2008-04-12T16:06:56  * ThomasWaldmann .oO(crap TestConfig)
2008-04-12T17:41:07  <CIA-47> Thomas Waldmann <tw AT waldmann-edv DOT de> default * 3496:ac14bdd08549 1.7/MoinMoin/security/_tests/test_security.py: tests: testing normal and hierarchical page acls (+ before/default/after acl)
2008-04-12T18:06:28  <CIA-47> Thomas Waldmann <tw AT waldmann-edv DOT de> default * 2619:543ae9bdbe26 1.6/ (3 files in 3 dirs): security fix: fix wrong acl processing for acl_hierarchic=True, refactor code so processing is similar for both modes, add tests
2008-04-12T19:54:29  <waldi> ThomasWaldmann: well, there is the old python-xml, the minimal variante in the python core and etree
2008-04-12T20:23:05  <ThomasWaldmann> definitely not python-xml :P
2008-04-12T20:41:47  <ThomasWaldmann> waldi: http://faassen.n--tree.net/blog/view/weblog/2006/02/24/0
2008-04-12T20:43:54  <waldi> it is not possible to use pickle on it
2008-04-12T20:46:28  <waldi> not really thread safe
2008-04-12T20:46:45  <ThomasWaldmann> hmm, bad
2008-04-12T20:47:58  <waldi> and a large dependency stack
2008-04-12T20:48:24  <ThomasWaldmann> "A major part of the XPath code was rewritten and can now benefit from a bigger overlap with the XSLT code. The main benefits are improved thread safety in the XPath evaluators and Python RegExp support in standard XPath."
2008-04-12T20:48:31  <ThomasWaldmann> from the 2.0 changes
2008-04-12T20:49:19  <waldi> "You should generally avoid modifying trees in other threads than the one it was generated in."
2008-04-12T21:03:18  <xorAxAx> ThomasWaldmann: you still want to give some points to adam after the code review - he has some code linked in a comment
2008-04-12T21:19:12  <ThomasWaldmann> done
2008-04-12T21:20:27  <xorAxAx> completly confusing when or why this app sends out mails
2008-04-12T21:20:36  <xorAxAx> esp. because he doesnt have any mentor assigned
2008-04-12T21:34:44  <ThomasWaldmann> btw, waldi told me he is a bit less present these days due to important private reasons
2008-04-12T21:49:14  <dreimark> johill: http://moinmo.in/ReimarBauer?action=AttachFile&do=view&target=session.patch
2008-04-12T21:50:01  <dreimark> I think we should check something like this in after_auth
2008-04-12T21:52:25  <kikka> moi
2008-04-12T21:52:27  <kikka> moin
2008-04-12T21:55:00  <ThomasWaldmann> wb dreimark and kikka
2008-04-12T21:55:23  <dreimark> hi ThomasWaldmann
2008-04-12T21:57:04  <ThomasWaldmann>   32 +            except KeyError:
2008-04-12T21:57:05  <ThomasWaldmann>   33 +                pass
2008-04-12T21:58:15  <ThomasWaldmann> (there is quite some code in that try/except)
2008-04-12T21:58:15  <dreimark> if there is no session standalone get's a KeyError for 'user.id'
2008-04-12T21:59:16  <dreimark> I found 1-2 other problems too
2008-04-12T21:59:45  <dreimark> a) sometimes it looks like if I do use standalone and a localhost wiki
2008-04-12T22:00:01  <dreimark> the wrong cookie is requested
2008-04-12T22:00:32  <ThomasWaldmann> how about session.get('user.id')
2008-04-12T22:01:05  <dreimark> b) the amount of session files
2008-04-12T22:02:12  <ThomasWaldmann>   15 -        session = request.session
2008-04-12T22:02:12  <ThomasWaldmann>   16          if user_obj and user_obj.valid:
2008-04-12T22:02:13  <ThomasWaldmann>   17 +            session = request.session
2008-04-12T22:02:32  <ThomasWaldmann> (cosmetic, but i think the old version is better)
2008-04-12T22:07:41  * dreimark dislikes session files starting with -
2008-04-12T22:09:30  <ThomasWaldmann> bad for rm * :)
2008-04-12T22:09:46  <dreimark> yeah
2008-04-12T22:12:20  <CIA-47> Federico G. Schwindt <fgsch@lodoss.net> default * 3497:2d257a89548d 1.7/MoinMoin/ (action/newaccount.py userprefs/prefs.py): Ignore empty emails if `email' is present in user_form_remove.
2008-04-12T22:15:43  <ThomasWaldmann> now we have 2 Federico committers :D
2008-04-12T22:24:21  <dreimark> ok, updated
2008-04-12T22:28:48  <ThomasWaldmann> looks better, but should be tested and johill please also should have a look
2008-04-12T22:28:58  <dreimark> sure
2008-04-12T22:31:49  <dreimark> hmm, it's currently not clear to me when expired sessions will/should be deleted
2008-04-12T22:32:32  <ThomasWaldmann> iirc it does some cleanup every 1000(?) requests
2008-04-12T23:12:02  <dreimark> gn
2008-04-12T23:16:17  <ThomasWaldmann> gn dreimark