Simple HTTP(S) request interface and UserAgents

[wouterl]

It could be nice if we have a somewhat higher HTTP/AJAX request interface. Maybe something similar to the jquery.get interface:

lightnion.get( url, date_we_want_to_supply, success_fun, error_fun)

This function should also set a sane default for the user agent. What? Optionally make user agent configurable.

[plcp]

Maybe related: curl.html

[plcp]

Should this call configure a circuit that'll live in a singleton stored somewhere in a global variable or configure a short-lived circuit that'll die after a single use?

Rephrasing: should next calls to lightnion.get use the same circuit than the first call (thus paying only one time the establishing a channel and extending the circuit two times cost) or each call will pay everything?

I'm in favor of the first case and I don't think that it'll be far harder to implement (with a simple rebuild-on-failure policy if the channel die at some point).

[wouterl]

I saw curl.html. I'm also not claimin this is going to be suuuuper difficult. But I think it'd be an good feature for users of the library.

About the circuit reuse, I'm inclined not to do that by default (but I'm willing to be persuaded ;)), but maybe we could do something like:

• lightnion.get always sets up a new circuit. So you have the nice fresh anonymous connection, in line with what I feel developers might expect. We can warn about the cost.
• To do lower cost, you'd first do circuit = lightnion.establish_circuit() or smth like that, and then do circuit.get. I'm not happy about naming it circuit though (both in function call and variable), but anonymous_endpoint sounds a bit vague too.

I would be inclined to avoid too much hidden state in general.

[plcp]

Yes, I'm in favor of such two-step workflows: first create a connection, then apply operations on it.
(and +1 on not hidding states, I was suggesting ideas to fit the API you were proposing)