gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] New network structure


From: Tomas Groth
Subject: Re: [Gnash-dev] New network structure
Date: Sun, 4 Mar 2007 14:02:34 +0100 (CET)

> > 
> > 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://....'.
> 

Exactly, so why not use the soon-to-come network_adapter?

> 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(). 

Yes, and this thread is what I'd like to move to the network code.

> 
> > 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 ?

I'm not entirely sure what you mean by "why"... I've already listed some of
curls shortcoming, which is the reason i think we should replace curl_adapter.

> 
> > 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.

I'll take it that you don't think network_adapter replacing curl_adapter in
StreamProvider is seperate enough...? Should we make a NewStreamProvider?


cheers,

Tomas


        
        
                
__________________________________________________________ 
Alt i én. Få Yahoo! Mail med adressekartotek, kalender og
notesblok. http://dk.mail.yahoo.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]