On Sat, Mar 03, 2007 at 12:18:20PM +0100, Tomas Groth wrote: > Hi all, > > Since the current network structure is based on libcurl, it has some of the > limitations of libcurl, which makes it hard to implement some of the features > needed, such as seeking in real streams, and obtaining the size of a file > being > downloaded. Also so far rtmp support in curl only exists in a separate patch. > > To solve this issue I'd like to suggest that we switch to our own network > code, > which is already in use in cygnal, though it will need to be worked on to > fully > support https and client side http and rtmp. > > Right now we connect/download stuff using StreamProvider, which returns a > tu_file pointer from curl_adapter, on which we read from, and data is > downloaded progressively using curl as we need it.
StreamProvider is just a provider for tu_file instances. It currently uses curl for non-local URLS, but could use any other thing. For example, it could use an rtmp-specific library if the url looks like 'rtmp://....'. Progressive 'as needed' download is not forced by this design. It is the returned tu_file user responsibility to do whatever it wants with it. If buffering is needed it could simply read() from the tu_file in a separate thread until get_eof(). > Instead of curl we should then use our own network code, and use a new > network_adapter like the current curl_adapter is used a an interface to curl. Why ? > Here is some of the changes from the current model: > > * When downloading, a thread to download the entire file should be started. > Since we want to be able to access the file meanwhile this should be done in > small chunks and using mutexes. When handling real streams the thread should > make sure X bytes is buffered at all time. > * We should probably use a circular buffer when handling real streams. > * Support for callbacks are needed, since LoadVars and NetStream (and maybe > others) needs support for something to happen (for example: start playback) > when X bytes has been loaded. I see all these functionalities best implemented in a separate class, taking a tu_file and providing thread-safe access to it. --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
