recursive types, struct, custom, dict, etc.

[Michael Meeks]

Hi Havoc,

	First - let me say, this is a cool E-mail :-) much as I'd like to see
some ABI goodness in the core, perhaps it's best to stick with the
iteration API etc. either way - it's an extremely encouraging direction.

	Anyhow - a few tiny comments.

On Tue, 2004-06-01 at 16:16 -0400, Havoc Pennington wrote:
> Reasons to make this change:
> 
>  - it's all elegant and stuff

	:-)

>  - it should clean up the code a bit, the code is currently doing
>    things both ways (for arrays and for everything else), though
>    keeping a variant type preserves the two ways to some extent

	Yes - although; in fact for arrays we need (effectively) 'memcopy'
optimisations, since handling common large arrays (eg. byte arrays) by
doing a byte-by-byte generic copy turned out to be slow in the ORB;
however - that can easily be done in a generic framework with some look-
ahead.

	One thing I didn't quite catch was the proposed string syntax for
structures; [ I imagine that fixed length arrays are really pretty
uniniteresting as a feature, but they could be similar ].

	Something like: "S3ibd" might be a struct with int, byte double in it
(?) ie. after 'S'  - decimals until alpha is the length.

>  - we can typecheck incoming messages with a single strcmp();
>    also overloaded methods could be more quickly routed

	Ok - _so_ I would in fact caution against this; one of the problems we
suffer(ed) in the a11y, and CORBA interfaces in general is the lack of
standardised forward/backwards compatibility; eg. to add a field to a
structure (eg. a timestamp) is just impossible, since we don't transmit
the type information in the message, and it has to be sychronised at
both ends.

	One of the things I like about D/BUS is the transmission of the type
information, so in fact we can do much better: I'll use my previous
suggested notation eg.

		caller			impl.

Old->New	S2sd			S3sdi
		"foo", 2.5	->	"foo", 2.5, 0

	ie. since we have the incoming and outgoing data, we can allow
structures (and API methods ?) to be painlessly extended with 0's for
backwards / forwards compatibility where appropriate.

	Of course, if we felt particularly complex, we could do more than just
extend them, but extending entails very simple code, and well it's just
good news really :-)

> So the summary I would say is that we should either drop array of
> array and go back to a straightforward hardcoded type list, plus an
> escape hatch of CUSTOM. Or we should go all the way and get the
> benefits of adding STRUCT and breaking type signatures apart from type
> codes.

	So - you know where my vote is; I'd really love to help, as you know.
Sadly my time is swallowed for the next months at least; conferences,
travel and OO.o stuff.

	Oh - finally - I wanted to say - and I think this is one thing that is
missed out, if we have a sensible structured mapping then we are no
longer faced with this dichotomy:

DCOP way:
	array<string> getMethods();
	string getMethodSignature(in string method);
	array<string> getSignals();
vs.
D/BUS way:
	XML-blob introspect();

	Where admittedly the XML-blob is far nicer than all these round-
tripping pieces to get stuff; but instead we can do:

	struct ObjectDescr introspect();

	and use our own (recursive) type definitions, to define our methods; -
which is well - IMHO more elegant, reduces the need to standardise the
XML format, allows extensibility [ assuming we do struct
extensibility ], and - well, it doesn't require bridging to another type
representation.


> Odds and Ends
> >===

> Struct names:
> 
>   I think there's a good argument to be made that struct names should
>   not be in the type signature or protocol, but instead be in the 
>   introspection data (where we also have arg names already, and could 
>   add struct field names in addition to the name of the struct
>   itself).

	Completely agree.

	Good stuff,

	Regards,

		Michael.

-- 
 michael at ximian.com  <><, Pseudo Engineer, itinerant idiot