Re: [Gnash-dev] New network structure

[strk]

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;