Re: EggDBus

[David Zeuthen <david fubar dk>]

On Mon, 2008-12-22 at 15:42 -0500, Dan Winship wrote:
> David Zeuthen wrote:
> > Yeah. I think XML-RPC types can largely be considered a subset of the
> > D-Bus types. For the datetime we could add an extra ISO8601 data type or
> > something (don't think GTimeVal is enough; need to preserve the TZ I
> > think).
> 
> Nope, XML-RPC dateTimes are (unfortunately) zoneless.

Oh, in that case I guess we can just gint64 that counts msecs since The
Epoch? (We'd want a typedef and GType as well I think)

> > I think "a{sv}" (a struct type in XML-RPC) can easily be mapped to
> > EggDBusStructure (or a subclass) the same way we already do.
> 
> I think it's pretty common in XML-RPC to have "struct"s with
> optional/variable fields. So at least some times, you'd want them to be
> EggDBusHashMaps. Maybe even most of the time.

Yeah. I've been toying with the idea of having a EggDBusNamedStruct
subclass of EggDBusStruct that would encapsulate this. Part of the API
in that class would be a way to get the hash map from strings to
variants. Another part of the API would be (convenience API) to check if
an element is set.

With such an API, you can still be able to declare structs in high-level
IDL and get nice GObject subclasses with type-safe API for accessing the
structure elements.

For things like XML-RPC with optional/variable fields it's probably fine
for user code to have to check if an element is available or not before
using the getter function; I mean, optional/variable fields is an
intrinsic feature of how XML-RPC works and is normally documented in the
interface spec for the XML-RPC interface in question. So the user will
need to know. Either way, this should mostly be a problem on the client
side.

(FWIW, the main reason the EggDBusNamedStruct subclass interesting for
the D-Bus use-case is that you can then declared a NamedStruct in your
IDL 

  <annotation name="org.gtk.EggDBus.DeclareNamedStruct" value="Point">
    <annotation name="org.gtk.EggDBus.Struct.Member"  value="i:x"/>
    <annotation name="org.gtk.EggDBus.Struct.Member" value="i:y"/>
  </annotation>

and the code generator would generate a subtype just like we do today,
e.g. the existing TestPoint type. The only difference is that we'd
marshal "(sa{sv})" over the bus with the first string being an
identifier for the struct, e.g. "named-struct:com.example.Frob.Point"
and the string->variant being the values, e.g. "x" -> 20, "y" -> 30. The
main win here is that you can extend this structure without breaking
API. An concrete example of why this is useful is this property

http://hal.freedesktop.org/docs/DeviceKit-disks/Disks.html#Disks:known-filesystems

in DeviceKit-disks. I'm pretty sure we need to grow that list of
properties at some point (with things like btrfs etc.) so I'm not
comfortable with the way that structure is hard-coded right now in
DeviceKit-disks.

Another example of where this technique is heavily used is
NetworkManager; lots of hashes of hashes of strings to variants are
shuffled around and GObject instances created on the client side from
that. That's a lot of code that ideally could be generated by things
like EggDBus.)

> > Right. The way I work around that is by generating code in the
> > GInterface. It's not ideal, I really want method and signal dispatching
> > to be generic. I think libffi might help here.
> 
> I was excited for a while about the libffi/generic signal marshaller
> bug, but I'm not sure it's really the right thing here; it's nice to
> have actual generated code, so that you can get compile-time type-checking.

I think you can still get type checking; we'd still have a VTable that
the user would need to assign function pointers to (we'd need the offset
in the VTable in the introspection data though). 

The only difference if using libffi, I think, is that we'd be able to
get rid of the generated handle_signal() and handle_method_call()
functions in the generated code:

http://people.freedesktop.org/~david/eggdbusproperties.c.txt

(Or did I misunderstand you?)

> > We'd also want to rename EggDBusVariant to
> > EggIpcVariant and EggDBusStructure to EggIpcStructure (ditto for
> > ArraySeq and HashMap but ideally these go into GLib proper).
> 
> EggDBusVariant isn't really IPC-specific either.

Right now there's a D-Bus specific thing insofar that you need to pass
the signatures for ArraySeq and HashMap but I'm pretty sure I can do
away with that if I just think a bit about it.

FWIW, there isn't really much to EggDBusVariant other than the fact that
it's just C-friendly front for GValue. 

(Oh, and that it's GObject derived which is extremely convenient as you
get to use all the useful GObject functionality (g_object_get_data()
etc.), a common free function, the ability to subclass it and all that
jazz.)

> (Whatever happened to
> GVariant?)

Ryan?

> > but normally people don't need that (and if they do, we can make it
> > transparent via e.g. PolicyKit); for desktop apps (XML-RPC probably
> > isn't interesting for system services; too dangerous etc.) people
> > normally set up security on a more coarse-grained granularity.
> 
> I don't have a use case for someone wanting to use the *same* API via
> both D-Bus and XML-RPC. I was just thinking that an app might use D-Bus
> for some things, and then also use XML-RPC for something completely
> unrelated, and it would be nice (both for developers and for bindings)
> if the APIs were similar.
> 
> (OTOH, it's possible that an app would want to expose both XML-RPC and
> *JSON* implementations of a service, which API-wise would be exactly the
> same as your D-Bus and XML-RPC example)

Yeah, I was mostly musing about the technical details. I completely
agree that the main goal here should be that the API used to consume /
export IPC services ideally shouldn't have to depend on the IPC
mechanism in question.

    David