Difference between revisions of "Certified HTTP API"

From Second Life Wiki
Jump to navigation Jump to search
(Initial notes on chttp api)
 
(→‎Client: Better idea here)
Line 13: Line 13:
     with_chttp(this_other_function, req)
     with_chttp(this_other_function, req)
   
   
  def this_other_function(req):
  def this_other_function(req, chttp_context):
     body = req.readbody()
     body = req.readbody()
      
      
     # this context method saves away the non-deterministic thing
     # this context method saves away the non-deterministic thing
     # during the initial execution, and spits out the saved value on subsequent runs
     # during the initial execution, and spits out the saved value on subsequent runs
     local = certified_http.context(some_non_deterministic_thing)
     local = chttp_context.persist(some_non_deterministic_thing)
      
      
     response = certified_http.post(escrow, "start transaction")
     response = certified_http.post(chttp_context, escrow_url, "start transaction")
      
      
     # see if we can make this post method capture a retroactive continuation?
     # see if we can make this post method capture a retroactive continuation?
Line 26: Line 26:
      
      
     coupon_code = local + response['random number']
     coupon_code = local + response['random number']
   
 
== Server ==
== Server ==



Revision as of 16:13, 13 September 2007

Certified HTTP API

This is the ever-evolving api for a Python implementation of Certified HTTP.

Client

Th major problem we face on the client is resumption. If you send a message, then you crash, what makes you not decide to send the same message with a new message-id? If you planned on sending a message, then taking some actions based on the response, how can you ensure that said actions get carried out on resumption? In the general sense, this implies that a certified http client must be able to capture and store a continuation.

There may be a way to capture a continuation automatically, but it seems unlikely that we'll be able to solve that problem in general, much more likely that the developer writing the chttp client will have to write continuation-friendly code. We need to have an API that allows you to conveniently store and restore the enough application state to serve as a continuation, and to unit test that you actually got all the state you needed!

def start_transferring_foo(req)
   # might not be necessary if we can inspect up the stack.
   with_chttp(this_other_function, req)

def this_other_function(req, chttp_context):
   body = req.readbody()
   
   # this context method saves away the non-deterministic thing
   # during the initial execution, and spits out the saved value on subsequent runs
   local = chttp_context.persist(some_non_deterministic_thing)
   
   response = certified_http.post(chttp_context, escrow_url, "start transaction")
   
   # see if we can make this post method capture a retroactive continuation?
   # or at least remove the need for an interstitial function definition
   
   coupon_code = local + response['random number']

Server

The paradigm on the server is actually a little easier to conceptualize, since we already have a handle method on the server that we expect to be called asynchronously. We still have to be careful about relying on module-level objects and other external contexts.

class Resource(mu.Resource)

def handle_foo(self, req):
    # we're already in a chttp context