[Pyogp] Updates and next steps

[Christian Scholz]

Hi!

With finally having svn access (is there a process in place now in case
some sprint happens and people need access?) I checked in some code.

The changes:

- cap objects will have proper names now instead of the memory address
when printed (just to make them look nicer). They also tell their URL then.

- The login now handles both the "normal" way of retrieving the seed
capability (via LLSD) and the way Linden Lab is handling it with the
redirect header (will this be changed)

- My doctest in login.txt passes now. For this I created a dummy
webserver as a WSGI application. You need to start it first with
bin/testserver before you can run the tests with bin/test. These tests
pass then. The server is implemented in tests/base.py (in the lib package).

- I added uuid, webob and wsgiref to the eggs needed as I am working
with Python 2.4 at the moment. This has no uuid and wsgiref shipping but
it should not matter. We can later remove it again. pyogp.lib.base also
depends on webob now which is a simple wrapper around a WSGI environment
giving one a nice Request and Response object. It is used in the test
server in tests/base.py

I hope everybody is familiar with WSGI as Linden Lab already uses it :-)
I really wasn't that much but read learned it a bit this weekend. Looks
quite nice :-)

Next steps I would like to do:

- create a branch for showing how grok works and how registering can be
done using it.
- create a networking layer abstraction. I was thinking along the lines
of some REST client which has methods such as GET, POST etc. which do
what their name say. It's basically a wrapper around urllib2 for now.

The advantage is then that it can be replaced for testing so that it
does not send anything over the network but instead calls the WSGI test
application in test/base.py directly and returns the result.

The question is what this network layer should return as urllib2 and
eventlet both probably return different things (other libs probably as
well). I was thinking about using the Request and Response defined in
webob as they seem to be good abstractions of a normal web request.
Moreover more and more python frameworks seem to use them.

You can read more about webob at: http://pythonpaste.org/webob/

What we probably need is request.headers and request.body, maybe
request.path

Converting this to and from urllib2 should be easy. Calling a WSGI
application with it is even more easy as it's meant to be used like that.

What do you think?
(btw, I have example code which does not work yet in the WSGI case but
should be fixable).

-- Christian

[Tess Chu]

Post by Christian Scholz
- create a networking layer abstraction. I was thinking along the
lines of some REST client which has methods such as GET, POST etc.
which do what their name say. It's basically a wrapper around urllib2
for now.

Locklainn is currently working with rdw to try to fix a bug in eventlet
preventing us from switching to it for the http client. This'll be
useful when the time comes to switch.

Post by Christian Scholz
The advantage is then that it can be replaced for testing so that it
does not send anything over the network but instead calls the WSGI
test application in test/base.py directly and returns the result.
The question is what this network layer should return as urllib2 and
eventlet both probably return different things (other libs probably as
well). I was thinking about using the Request and Response defined in
webob as they seem to be good abstractions of a normal web request.
Moreover more and more python frameworks seem to use them.

Would be good to have a common interface for testing.

Post by Christian Scholz
You can read more about webob at: http://pythonpaste.org/webob/
What we probably need is request.headers and request.body, maybe
request.path
Converting this to and from urllib2 should be easy. Calling a WSGI
application with it is even more easy as it's meant to be used like that.
What do you think?
(btw, I have example code which does not work yet in the WSGI case but
should be fixable).
-- Christian