Re: [boost] [soc07][cgi] RFC: use-cases/scope

From: Darren Garvey (lists.drrngrvy_at_[hidden])
Date: 2007-04-25 12:19:07

On 23/04/07, Martin Wille <mw8329_at_[hidden]> 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