On 23/04/07, Martin Wille <mw8329@yahoo.com.au> wrote:
Darren Garvey wrote:
On 22/04/07, Martin Wille wrote: [...]
Noted. Incidentally, I figured WSGI wasn't a protocol per-se, but a framework for handling multiple protocols?
Hmm, you seem to be right. The text at http://www.wsgi.org/wsgi/What_is_WSGI mislead me, as it somehow seems to imply a protocol.
I really wasn't sure myself; I had to reread that a couple of times to be 'sure'. *sighs* [snip]
Well, then it's better to do what can be done within the timeline well instead of failing the job in the attempt to add a boatload of features.
Yeah, I agree. The library isn't exactly Rome, but I should probably build it using the same rules (ie. in stages).
I wonder how controversial this would be? I suppose it'd be quite simple to
implement and easy to remove if it was a problem.
Which do you expect to be controversial: session management per se or cookie-free session managment?
I expected session management in general to be controversial - mainly because it involves security, which usually seems to fan flames - but the idea seems to have support. Of course adding support isn't vital, but I think this'll be first on the list of things I'll do if all the rest goes to plan. I was not talking about C++ streams. I was talking about sending a
stream over HTTP, see http://en.wikipedia.org/wiki/HTTP_streaming
Oh yeah! :) IIUC, support for HTTP streaming requires only two things: the ability to say the transfer encoding is chunked, and some way to route requests from the same user to the same place. If that's all, then streaming wouldn't actually require any extra library code to use. (please correct me if I'm missing something) If, for example, you had ticker info for a client, you could send out a bit, then notify the program what state the client is in (ie. how far along the ticker they are). When another request comes in you just look up the client state, go to that point in the tracker and continue processing. Alternatively, you could supply your own event handler to the library (this is something that should be possible anyway, IMO) which _does_ route requests; routeing by default would probably incur too much overhead. Thanks, Darren