dvfs api and toolkits

[Sean Middleditch]

On Tue, 2005-04-05 at 15:08 +0100, Jamie McCracken wrote:
> Sean Middleditch wrote:
> > On Tue, 2005-04-05 at 14:20 +0100, Jamie McCracken wrote:
> > 
> >>Do you mean should the backend drivers be GObjects?
> > 
> > 
> > No.  I was referring to whether the client-side API be focused around
> > interfaces and querying,  How the backends are implemented have zero
> > impact on the client API since the backends will only be interacted with
> > through the IPC mechanism.
> 
> okay, sorry.
> 
> I would however encourage you to implement the client side as full OO as 
> GNOME is already moving in the direction of making documents first class 
> objects.
> 
> I also see the API as being much more pleasant with objects. EG take a 
> document object it might have methods load/save/cancel associated with 
> itself and signals/events for Document_Loaded and Document_Saved which 
> means you can avoid exposing a nasty async API and keep everything KISS.

As mentioned before, I don't expect apps to directly use D-VFS, but
instead to use a toolkit-specific wrapper.  If the glib wrapper wants to
be OO, that's perfect.  My question is, should the D-VFS API itself,
which will normally be hidden/abstracted behind a toolkit API, also be
implemented in its own OO knock-off or something simpler?  Which would
be easier to make both OO and non-OO wrappers in?

The difference between the two are minor, but could have some very big
impacts on wrapping none the less.  Basically, with the interface
approach, you do something like:

  handle = vfs_open_for_read(url);
  seek_interface = (VFS_ISeek*)vfs_query_iface(handle, VFS_ISEEK);
  if (seek_interface)
    vfs_iseek_seek_to(seek_interface, 0);
  else
    error("Can't seek file");
  vfs_close(handle);

With no interfaces, it would be something like:

  handle = vfs_open_for_read(url);
  if (vfs_has_capability(handle, VFS_CAP_SEEK))
    vfs_seek_to(handle, 0);
  else
    error("Can't seek file");
  vfs_close(handle);

or even just:

  handle = vfs_open_for_read(url);
  if (vfs_seek_to(handle, 0) == VFS_ENOTSUPP)
    error("Can't seek file");
  vfs_close(handle);

Not really all that different at a glance, are they?  The interface
version is a little more complex because you have to get a reference to
an interface object, and consequently will have higher overhead and more
code since the client API has to get all the capabilities from the
backend over the IPC mechanism in order to internally construct the
handle object appropriately and set things up.  It's a lot of pain that
a simple list of "does support" flags and a "has flag" function
completely negates.

Additionally, the interface approach could make it *harder* to wrap the
API - we'd have our own little mock OO system that won't map directly to
or use the same data types as the OO system we'd be wrapped in.  The
capabilities querying approach is very, very easy to wrap in both an OO
and non-OO language - you could even add interfaces on top of the
non-interface D-VFS API with relative ease.

I don't see any actual benefit to doing the interface approach in D-VFS
itself, and I see some stark disadvantages, although I'm open to
counter-arguments if I'm missing something vital here.  ;-)
-- 
Sean Middleditch <elanthis at awesomeplay.com>