On Tue, May 10, 2011 at 09:04:42AM +0200, Roman Puls wrote: > whilst this might be nice for flow-blown web services, this does not > work for embedded systems that have no or very limited disk storage. > > Also, this pattern disables effective stream handling, e.g. where > you don't want to store and process, but do some operation like > decompression and further post-processing in "real-time". > > Instead, my suggestion is to process chunk-wise, and optionally > provide a chunk-handler that streams to a file.
You forgot to quote the bit where I said it was a toggle.. To this point, the act of spooling doesn't have to be a file write, it can be any file descriptor, one that you could say, install a handler for. In an embedded environment, even a single chunk can be very large. If it's a "per-chunk" callback you are asking for - this has been done, I wrote the patch months ago. This ability actually already exists within the current code. The issue was that the only way you could "enable" this feature was from a client -> server connection. But on the backend it uses the same function for chunks for both server and client.. The solution was to add a secondary callback that gave you access to a request post-header-parsing / pre-body-read, at which time you could set the chunk callback previously accessible only to clients. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
