Open justinabrahms opened 11 years ago
Yeah that's a good point. What we could add is 2 new functions in the behavior base class:
on_before_backend_call and on_after_backend_call would be the place where the protocol has transformed incoming and outgoing data into protocol specific data. In the case of HTTP: an http query and response.
So in the case of HTTP, you'd write:
class SlowQueryBehavior(Delay):
name = 'slow_query'
options = {
"to_match": ("File ending to match", str, ".json")
}
options.update(Delay.options)
def on_before_backend_call(self, protocol, source, backend):
request = protocol.get_data()
ext = self.option('to_match')
if request.PATH.endswith(ext):
gevent.sleep(self.option('sleep'))
return True
Of course it implies that each protocol documents what .get_data() sends back. How does that sounds ?
@ametaireau what do you think?
This would be ideal for my case. :smile:
Right now, the behavior interface deals with sockets, which puts a lot of additional complexity onto the implementor when only wanting to deal with HTTP level things.
My use case is: I have an app that uses local storage as a read-through cache where we return the stale data initially, then refresh it with an async RPC.
I'm having difficulty reproducing caching errors because my local development server is too fast and the refreshing RPC returns at the same time as the localStorage results return. I need to slow down queries to specific endpoints in my app. Ideally, my code would look something like:
As it works now, I'll need to handle reading out of a socket, parsing the HTTP bits to make my decision, then forward it along fixing the drained socket.