- From: Stefan Kost <ensonic hora-obscura de>
- To: Alexander Larsson <alexl redhat com>
- Cc: gnome-vfs-list gnome org
- Subject: Re: GNOME_VFS_OPEN_RANDOM
- Date: Thu, 23 Nov 2006 20:15:24 +0200
Alexander Larsson wrote:
> On Mon, 2006-11-20 at 15:42 +0100, ensonic wrote:
>> there is http://bugzilla.gnome.org/show_bug.cgi?id=354590. Its about a
>> property to tell gstreamer gnomevfs source to use GNOME_VFS_OPEN_RANDOM or
>> not. Now people are quite against adding that. None other know filesystem
>> needs a flag like this.
>> When opening an http uri, after the first get request gnomevfs should know
>> if seeking is possible. If not seek calls can be made to fail. If there is
>> a seek without a previous get, you will probably need to get 1 byte and
>> keep that, so if seek is not possible and the app next reads 10, bytes
>> you'll read only 9 and put the one already read in there first.
>> if that totaly makes no sense, any ideas about the bug?
> In some cases its possible to do a better job if you know that there
> will never be any seeks. You might for instance have to do some ugly
> hacks to implement it that hurts the streaming case. For instance, seeks
> and writes to an open handle is complicated in many backends.
> GNOME_VFS_OPEN_RANDOM also unfortunately have some ugly API entaglement.
> It also defines if opens for write truncate or not, and its also used as
> a hint for streaming optimizations.
> Anyway, what you propose, an open for random access not failing even
> though random access isn't supported would be an API/ABI break, so that
> won't happen.
> I don't see why you can't just try again without random if it fails
> though. How is that different from failing in the seek later.
Thats what I tried first. Technically it should work, but some servers
are picky. E.g last.fm blocks clients that try to open twice shortly :(
] [Thread Prev