Hi Koen,
> No, you would implement your resource simply writing
> everything to it in one go.
> But, memory usage would be limited to an internal I/O buffer, and the
> write() would block while the buffer is being transmitted.
>
> So, during this synchronous I/O, you would keep using the
> same thread until the entire resource is streamed to the browser.
OK. Writing to the buffer would cause the data to be transmitted, if I
understand correctly. If this method is implemented, I suggest that it should
be possible to set the buffer size programmatically.
> Instead, an asynchronous way of doing would be in pseudo code:
>
> void streamNextPart() {
> if (resource.hasMoreData()) {
> // .. get next data chunk
> ...
>
> // send to browser, and supply a callback to be called when done
> sendAsyncToBrowser(..., &streamNextPart);
> }
> }
>
> The latter approach has the benefit of being entirely
> scalable in all situations, but is more complicated, and for
> an embedded platform this scalability (towards many
> concurrent threads) is not an immediate concern.
>
OK. But again, please make it possible to control the chunk size.
> Both solutions solve your problem, imho, and so we will pick one.
Sounds great. I'm ready to test it as soon as it is ready :)
--
Med venlig hilsen / Best regards
Michael Sørensen Loft, Mjølner Informatics A/S
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
