Hi Alex, Alexander Larsson wrote: > On Mon, 2006-11-20 at 15:42 +0100, ensonic wrote: > >> hi, >> >> 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 :(
Stefan _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
