[Top][All Lists]
[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