dvfs api and toolkits

[Ikke]

> 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?
Making an OO wrapper lib to a non-OO lib seems much easier to me than
the other way around.

The DBUS also take this approach: a non-OO base structure, which in
theory shouldn't be used too much by applications directly, and
glib/Qt/Python/Mono/... OO or non-OO wrappers on top of it.

If the basic framework is OO based, I dont think people will write
non-OO accessor functions etc, because thats a hassle (non-OO to OO is
already automated for some languages, not the other way around), and if
no non-OO bindings are provided a lot of people wont be willing to use
DVFS I think.

Take this as an example: both Glib GObjects and QT C++ classes are
"objects", but they differ a lot at lower level (I'm not talking about
the languages (C/C++) here, but the low-level object representations,
functionality,...). My knowledge to this subject is very limited
though ;)

Ikke
http://www.eikke.com