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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list