dvfs api and toolkits

[Waldo Bastian]

On Sunday 10 April 2005 01:22, Nate Nielsen wrote:
> Avery Pennarun wrote:
> > On Sat, Apr 09, 2005 at 04:33:29PM -0400, Sean Middleditch wrote:
> > Movie players are, however, a good example of where seekability might be
> > important.
>
> <snip>
>
> > That said, this is a pretty special case.
>
> I beg to differ.
>
> - Read an archive format like ZIP, TGZ or ISO  User opens the file in
>   their choice of archive manager. The user then proceeds to extract
>   a file. Now the entire ISO/ZIP/TGZ (your choice of archive format)
>   needs to download until the point of the file to be extracted.
>
> - Note that some archive formats don't contain the 'file content list'
>   at the front. In some cases it's at the end of the archive.
>
> - ID3 version 1 tags are (mostly) stored at the end of MP3 files. To
>   display information about an ID3v1 marked MP3 file, a music player
>   would have to wait for the entire file to be loaded.
>
> - PDF viewers often choose to to seek around, showing text and skipping
>   large images. PDF's can be very large in many settings. A good PDF
>   implementation allows the user to go to different pages before the
>   images or even the entire content of their previous page has completed
>   loading.
>
> - Seeking in a movie is of course a show-case example. The user doesn't
>   (or rather shouldn't) expect the massive wait involved.
>
> These are just some examples. And note that these are in fact
> 'documents' as far as the user is concerned. The user is working with
> his document (or music file, movie, whatever), and isn't expecting the
> kind of delays we're talking about here.
>
> Ideally file (ie: document, movie, archive, music) formats wouldn't have
> these issues. But because we don't live in an ideal world so we have to
> consider these things.

I would say that for now DVFS shouldn't support seeking and later on we can 
have a look at applications like you mention above and see what there *exact* 
needs are. For now they should just download the whole file and seek in 
there. Later we can make that more optimized on selected backends (mostly 
centered around http I imagine) I don't think it makes sense to do a poor 
attempt at generalization at this point if the chance is large that the 
result of that will still be unusable for the targeted applications.

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050410/dc93c875/attachment.pgp