dvfs api and toolkits

[Kevin Krammer]

On Sunday 10 April 2005 16:11, Sean Middleditch wrote:
> On Sun, 2005-04-10 at 13:04 +0200, Waldo Bastian wrote:
> > 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.
>
> I agree on this point.  We could even very well have seeking figured out
> by 1.0; it's hard to figure out what will actually work here without
> having code to test against.  Even if it misses 1.0, we can always get
> it in 1.x down the road.

The following is just based on observation of user feedback from KDE's 
mailinglists with regard to audioplayers handling file over KIO:

The users normally don't expect to work with a HTTP/FTP URL like they do with 
a local file, they treat it like one of those streaming technologies.

On the other hand they don't understand why their player application would 
treat a smb:// URI so differently than smbmount'ing the share and playing the 
file from the mount point.

Even users that make heavy use of KIO don't expect all protocols to work equal 
across all operations, but they expect protocols they can also access on the 
system level (for example file:///) to work at least as good as the system 
level access method.

Cheers,
Kevin
-------------- 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/1e854ad2/attachment.pgp