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
MoinMoin: MoinMoinChat/Logs/moin-dev/2008-04-12 (last edited 2008-04-11 22:30:02 by IrcLogImporter)