Add support for middlewares / plugins

[almet]

And activate some of them by default.

For instance, that would be useful to have more than one service url, and to fallback to the other ones if the fist one fails.

Some code for that is implemented in https://github.com/mozilla-services/queuey-py/blob/master/queuey_py/client.py

[Natim]

Yes, I am thinking of a HeaderContext that would prepare the header and data of a request.

from respire.context_processors.http_auth import HttpAuth
SPORE_CONTEXT_PROCESSORS = (HttpAuth(username='x', password='ducksboard_key'), )

client_from_url('SPORE_URL', HeaderContext())

HeaderContext should have a update method that will get a self.headers and self.data and return them after having added necessarily information.

[almet]

I don't get why we should name that differently than a middleware, to be honnest. I don't think either "header" or "context" are right. "processors", why not.

"Middleware" has the advantage of exposing clearly that it does something before the request is given to us, and after. "decorator" could be another name.

If we're using requests, we could probably attach some information to the request/response objects on the fly, and that could be enough, no?

[Natim]

How do you create a request before to send it with requests?

[Natim]

Your description would be a middleware.
How can you pass your request through middleware before to actually send
the request using requests?

2012/10/24 Alexis Metaireau [email protected]

I don't get why we should name that differently than a middleware, to be
honnest. I don't think either "header" or "context" are right.
"processors", why not.

"Middleware" has the advantage of exposing clearly that it does something
before the request is given to us, and after. "decorator" could be another
name.

If we're using requests, we could probably attach some information to the
request/response objects on the fly, and that could be enough, no?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-9740612.

[almet]

That's a middleware: that does something like that:

client → middlware(request) → requests → middleware(response) → client

[almet]

(we need to use the requests internal objects)

[Natim]

I thought with a context_processor we would be able to do it without hacking on requests.

[Natim]

We can also make a RespireRequest object and then use the call method to actually send the request.

[almet]

hmm, I see the reasoning now. I find it kind of weird to control the arguments we pass to the request lib, but that makes some sense. We need to dig into requests internal to see what makes more sense.

[almet]

after digging a bit more in the codebase, it seems that having our own request object which will do the call to requests makes more sense.