diff options
author | Søren Sandmann Pedersen <sandmann@daimi.au.dk> | 2009-04-13 22:18:12 -0400 |
---|---|---|
committer | Søren Sandmann Pedersen <sandmann@daimi.au.dk> | 2009-04-13 22:18:12 -0400 |
commit | 87eeadfde446178d11944562e75e056356bbb83f (patch) | |
tree | 54de3cb9dac8c4885812b9025f1d94f7b09643cc | |
parent | 9726da802284076a486e23a5d09b7920f1260b8f (diff) |
TODO
-rw-r--r-- | TODO | 16 | ||||
-rw-r--r-- | dbus.c | 1 |
2 files changed, 16 insertions, 1 deletions
@@ -100,6 +100,22 @@ from the stack. Write tool that reads the introspection XML and generates service code. +Can we use the same type system for dbus and sfile? The sfile type +system is basically name/type pairs, which is approximately what dbus +needs as well. + +For dbus we will need structs of basic types, arrays of basic types, +and probably arrays of structs of basic types. Arrays will be +represented in C as "int n; const type *array". I suppose it would be +possible to generate the fully nested types, but it's pretty crackful +that that's even supported in dbus. + +For the introspection types, we don't need the names, so those types +will probably have to be specified in some other ways. One question is +if it is only the specification or also the actual types that are +different. + + Things from glib: - Consistent API between things like GCheckSum and GBase64. @@ -974,7 +974,6 @@ make_fun_def (nul_dbus_member_t *member) nul_ptr_array_len (member->parameters) + 1)); types[0] = NUL_TYPE_POINTER; /* For object->data */ - g_print ("length: %d\n", nul_ptr_array_len (member->parameters)); for (i = 1; i < nul_ptr_array_len (member->parameters); ++i) { nul_dbus_parameter_t *par = member->parameters[i - 1]; |