dvfs api and toolkits

Jamie McCracken jamiemcc at blueyonder.co.uk
Tue Apr 5 16:20:51 EEST 2005

Sean Middleditch wrote:
> On Tue, 2005-04-05 at 11:00 +0200, Kevin Krammer wrote:
>>On Tuesday 05 April 2005 05:32, Sean Middleditch wrote:
>>>Some backends might have relatively efficient support for seeking, and
>>>it might be possible to design the API in such a way that it can
>>>transparently support either native seek support or local-copy
>>>emulation.  Doing that could get tricky, though, in some cases - what if
>>>you open a large file on a backend that doesn't handle seeking but just
>>>stream it in?  Should the system try to create the temporary copy
>>>anyhow, or should the API require the developer to explicitly state, "I
>>>want this file to be seekable" ?
>>Maybe just some protocol info like is capable of seeking forward (skipping), 
>>capable of seeking backwards.
> Indeed, that's the idea.  I'm still torn between an OO-interface style
> that the gnome-vfs guys seem to want and something more simple like a
> has_capability function.  I don't think the interface approach will make
> anything particularly easier without actually doing the whole interface
> OO-like with inheritance and all that goodness, which isn't something
> I'm going to attempt in C.  (Not even with glib, although the glib
> bindings to D-VFS can very well be OO.)

Do you mean should the backend drivers be GObjects?

I would say yes to that seeing as glib is (or will be in v4) acceptable 
to the KDE folks. It should make writing backends easier as the 
hierarchy should provide suitable ancestors for drivers of varying 
complexity (imagine having a POSIX ancestor for backends which are 
similiar to posix - that would save a lot of time) and for the different 
types (async/sync drivers). Minimising both the amount of work and the 
learning curve for creating new backends would be greatly beneficial.


>>xdg mailing list
>>xdg at lists.freedesktop.org

More information about the xdg mailing list