dvfs api and toolkits
bastian at kde.org
Sun Apr 10 14:04:52 EEST 2005
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.
> > 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
> - 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050410/dc93c875/attachment.pgp
More information about the xdg