[PEAK] Does a PEAK-ized webware esist ?

[Phillip J. Eby]

At 04:40 PM 1/30/04 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 03:58 PM 1/30/04 -0600, Ian Bicking wrote:
>>
>>>Wayne Larsen wrote:
>>>
>>>>That is what I was looking at -- I was trying to understand how 
>>>>peak.web   maps from a url to an actual resource, since I have a 
>>>>feeling the solution I'm looking for is some combination of the two.
>>>
>>>
>>>Well, if you are running PEAK (or peak.web, I suppose) inside Webware, 
>>>then you'll want a URLParser that delegates to PEAK's URL parsing.
>>
>>For 'peak.web', it's not really PEAK's URL parsing.  'peak.web' uses Zope 
>>X3 request and response objects, so it's probably not going to live 
>>happily inside of Webware.
>
>Really?  It's been a while since I looked at those objects, but it seems 
>like it should be possible to subclass them so they delegate to Webware's 
>request and response instead of reading out of 
>stdin/stdout/environ.  Environ is already present, and I believe Zope's 
>HTTPRequest.__init__ is close enough to Webware's HTTPRequest.__init__ 
>that you could map the resulting internal data structures.  And Zope's 
>HTTPResponse, if I remember, is pretty simple.

Those things might be possible, but *I'm* not going to do them, so let me 
rephrase and say that 'peak.web' won't live happily under Webware without 
somebody else doing a lot of extra work.  :)

I reused Zope X3's stuff specifically so I wouldn't have to go through the 
tedious process of implementing Yet Another Request/Response Type.  :)  Ty 
has occasionally claimed that replacing them should be easy, to which I 
always reply that I'm happy if he wants to write them.  :)


>I don't know about traversal, but I don't know why it wouldn't be 
>doable.  URLParser returns a Webware servlet, not a path to a file, so the 
>wrapper only has to wrap the Zope object in a servlet.

'peak.web' expects to have an 'interaction' at the center of the universe, 
that references the request, response, skin, etc.  This interaction manages 
the start and end of the PEAK transaction, among other things, as I 
mentioned today in another post.  It simply isn't built to mix in with 
something else.  You might be able to make an interaction class that 
manages to do what you need, but at that point you're writing your own 
framework.

So, my point about these things isn't that they're impossible, just that 
you're "on your own".  I build PEAK stuff with more configuration points 
than you can shake a stick at, and thus it's *possible* to do darn near 
anything with them.  It's just that once you wander off the beaten track, 
there are fewer civilized conveniences available.  :)


>>That doesn't mean you can't have PEAK components inside of Webware, just 
>>that 'peak.web' isn't going to be able to do traversals in there, unless 
>>you can bridge back to a WSGI-style 'runCGI()' call.
>
>That might be an interesting feature, i.e., to wrap the response in a 
>stdout-like object, and serialize the request back into a stdin-like 
>object, and rewrite a couple environmental variables to represent the new 
>context.

Yep.  Of course, it'd be cleaner to write a pure WSGI traverser, since 
stdin and stdout are unaffected by all that, and you wouldn't need to make 
lots of wrapping layers.  It's why my proposal called for using a 
modifiable dictionary as the 'environ', as such a traverser could just 
update the dictionary in place before forwarding the request to another 
service.