D/BUS IDL compiler ... #2 ...

[Havoc Pennington]

Hi,

On Thu, 2004-03-25 at 12:07, Michael Meeks wrote:
> 
> 	* What should the 'name' of a return value be ? or nothing ?
> 

A return value is just an "out" arg (D-BUS has no distinction); for all
args the XML parser currently allows name to be omitted, it's just an
annotation for human readability.

> 	* Is 'oneway="true"' a sensible thing for oneways, and
> 	  is it acceptable to not emit oneway="false" ? - I never
> 	  much fancied XML attributes & booleans.

D-BUS calls oneway "no reply" - see dbus-message.h

This is note a property of the caller, not a property of the
server/interface. i.e. any caller can add the "I don't care about a
reply" flag to their request. They may or may not get a reply at that
point.

Or with dbus-gproxy you have the option to call
dbus_gproxy_call_no_reply() or use begin_call/end_call to get the reply.

This poses a problem we should think through then, since we're using the
interface definition both to introspect and to generate the caller-side
stubs.

> 	* Is it an acceptable constraint to demand that any 'out'
> 	  values [ which currently I don't support ] be a
> 	  contiguous block of arguments at the end of a method call ?

This is automatic on the protocol level (the "in" args are in the
outgoing call, and the "out" args are in the reply). If you want to
enforce that for the C stubs you generate the args are always in that
order it probably makes sense to require it in the IDL also, just so
people don't get confused.

> 	* For recursive / more powerful types [ ie. map(Foo, Baa) ] does
> 	  it seem  resonable to demand a preceeding 'typedef' and a
> 	  by-name reference ? then I guess we can add semantic richness,
> 	  and stronger typing to many backends:
> 
> 		+ that would involve a type definition node perhaps:
> 	
> 	 <typedef name="org.openoffice.foobaa.NameAccount" type="map">
> 		<field type="string" name="Name"/>
> 		<field type="string" name="Account"/>
> 	 </typedef>
> 
> 	  This of course allows a dynamic binding to instantiate that
> 	 type, and do foo->name = "jim", foo->account = "nn132", instead
> 	 of something more opaque. [ we do this for the CORBA binding
> 	 with some nice effect ].

We would have to say something like:
 - all needed typedefs must be included in an Introspect() response
 - the scope of a typedef is only the node/object that was introspected

Would also have to introduce some sort of way to represent and check the
type definition.

I don't know, I don't think we can answer this in isolation, we need to
go back and resolve the earlier discussion about complex and CUSTOM
types and have a comprehensive answer to the whole issue.

> 	* attributes / properties
> 
> 	    + I see the code in dbus-object.c(handle_introspect)
> 	    throws away the 'property' semantic; mapping it to
> 	    a 'get_' / 'set_', this is IMHO a mistake. Many languages
> 	    have a nice attribute mapping that would suck much more
> 	    to use methods everywhere

I'm just copying C# here ;-) it maps 100% cleanly into .NET ;-)

To me it's quite reasonable to just specify that anything starting with
get_/set_ is a getter or setter for an attribute. Or if you wanted to be
really particular, specify that anything starting with that and the
appropriate one-return/no-args or one-arg/no-return semantic is a getter
or setter. Especially because the D-BUS convention is javaCaps not
c_underscores.

This preserves the property semantic without adding any extra code or
features to libdbus or the daemon.

> 	    + CORBA does something similar, but uses '_get' on the
> 	    wire - ie. a magic (not usable by other methods) '_'
> 	    prefix for this internal foo.

i.e. basically I'm saying do this, but the "not usable by other methods"
is just by spec, if someone wants to create a method set_Foo that
actually frobates instead of setting Foo, we can't really stop them.

> 	* is 'access' a good name for the 'a11y' of the attribue ;-)
> 	  how about the suggested values - lots of different ways to
> 	  do that.

Just have or don't have the set_/get_ method right? At least in the XML
format. In the IDL, access seems like a fine term. Copy some existing
system like C# is probably safest.

> [1] - what programmer would prefer to read an interface contract as this
> blob of XML (and this for a hyper-simple interface) than the IDL
> fragment ?

No question the IDL is more human-readable, but remember I'm looking at
using the XML as format to transport data between two programs; the
human-readable form is your native language format typically.

Languages universally have an XML parser people already know how to use,
which isn't true for IDL. The primary consumer of the Introspect()
format should be language binding authors.

The human-readable IDL is just a language binding that chooses to have
the programmer write an IDL file and then generate the native language
file from that, instead of parsing the native language file. In other
words the IDL in this case is really specifying an implementation not an
interface ;-)

Maybe the right thing to do then is declare that IDL is never installed,
and neither are the XML files; IDL is only something written in your
source tree as a way to generate C files, the XML is only the
Introspect() return value.

Havoc