Hey,
2010/11/11 u.nn <[email protected]>:
>> Given that you insist on being able to do this with plain HTML as
>> well, I guess Wt does indeed not support this. Although Wt uses an
>> asynchronous model for I/O (for http and isapi connectors), it
>> currently uses a synchronous model for delivering an event and
>> rendering the response.
>>
>> Can I ask why you really want this, since deferring the response to
>> the browser for a plain HTML request is usually going to give rather
>> bad user experience ?
>
> I'm not sure I follow that (from the user perspective, it should be the
> same as with a synchronous response). I don't really see how else to
> provide information derived from a (high-latency) outside source without
> doing something like this.
I agree with this: from a user perspective this is the same, but I was
just saying that you may not want to delay the response too long.
> Or of course, the third option is to require suitable AJAX and use
> server-push :) But that's not an option for me.
But, would you not hope that the majority of your clients has
Ajax/WebSockets capabilities and thus the plain HTML alternative will
not be used that much so that you can afford it to be less efficient
in terms of blocking threads ?
> That is good to hear. I was fearing that if this were not already
> possible in Wt, then it would require radical restructuring (as the
> conversion from sync -> async usually does). If that were the case, I'd
> have little hope of support for such a thing that most people don't care
> about :)
It will not require radical resturcturing, but it will require adding
a bit of implementation and API. Wt already decouples a request
handling (WebSession::handleRequest()) from committing the response.
This is used for e.g. long polling or recursive event loops. There is
no inherent reason why you cannot do this for an HTML response too.
The important steps look like this:
WDeferredResponse WApplication::deferResponse()
{
return WDeferredResponse();
}
WDeferredResponse::WDeferredResponse()
{
// Uses thread-specific data to get the current 'handler'.
// A handler is a short-lived object that is created for the duration of a
// thread accessing a session.
WebSession::Handler *handler = WebSession::Handler::instance();
// Copy the current request/response from it
request_ = handler->request();
response_ = response->response();
// Set them to 0. In this way, Wt will no longer try to commit them.
handler->setRequest(0, 0);
}
void WDeferredResponse::commit()
{
WebSession::Handler *handler = WebSession::Handler::instance();
// Checks that we have an update lock but are calling this out of
the normal event loop
assert(handler && !handler->request() && !handler->response());
handler->setRequest(request_, response_);
// For a plain HTML session:
handler->session()->render(*handler, WebRenderer::Page);
// For an AJAX session you would pass in WebRender::Update, but I
would argue that in
// that case you have better options.
}
This pseudo-code does not deal with specifics of doing this for the
very first request -- I would recommend trying this only for a running
application first.
> And as far as usefulness... well, I think I'd find it useful for me, so
> I don't mind doing the legwork. Obviously, include it in Wt itself or
> not as you wish :)
We would prefer to integrate it, yes. If only because it requires
internals of Wt which would mean you need to keep it as a patch.
> Oh yes, certainly; I fully expected to be doing all of the work that
> might be necessary. Just don't expect me to be doing so very quickly;
> while I definitely will be looking into this and am interested in any
> pointers you have to give, most of my time is occupied with other
> things.
Regards,
koen
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
