memory freeing necessary?

[Matthew Johnson]

On Tue, 25 Jul 2006, Havoc Pennington wrote:

>> and other services do the same? Should the file extension be ".xml". Or
>> do we want a dbus specific one, e.g. ".dbus-introspection-data"? What's
>> the MIME type going to be (for example what about
>> "application/dbus-introspection-data" or do we not need one?
>
> I don't know here, what do other apps do?

A fairly even split, I think. We aren't really pushing this as a Format
(cf open document, xsl, etc) and nothing needs it as a separate
mime-type, so .xml is fine imo

>>  - Should we require or just encourage apps to drop files there? Some
>>    apps are not really are introspectable (hal just gained this in CVS
>>    HEAD a month or two ago, NM still don't IIRC) and some never will,
>>    so suggest to not require it.
>
> I think encourage.

I think _all_ apps should be introspectable. It's a condition of the
bindings that they provide this, I think a c-api dbus program which
doesn't should be considered a bug.

> I think I actually said "exceptions are part of the defined semantics of a 
> method, even though they aren't in the type signature, and you have to 
> specify non-compiler-checked semantics in an ABI anyway and exceptions would 
> fall under that spec"
>
> IOW exceptions can't be added if they break the semantics, so your previous 
> bullet point applies ;-)

So can we please have annotations that list them? If it's part of the
API/ABI it should be in the introspection data.

>>  - can you add IN parameters to methods / signals? In the C ABI you can
>>    do this
>
> This would break source compatibility.
>
> We may want to change dbus_message_get_args() (and corresponding routines in 
> the glib, etc. bindings) to throw an error if there are extra args so people 
> don't do this... one for the TODO
>
>>  - can you add OUT parameters? In the C ABI you make a function
>>    returning "void" return something provided, of course, you don't
>>    need the caller to free it
>
> Seems like a similar case of may break source compat though it doesn't break 
> wire compat.

The Java bindings enforce this anyway; the method is looked up via an
(object,interface,method,args) tuple, which allows overloading; return
types are all strongly typed so you will get a runtime error if the
wrong type is returned.

Matt
-- 
Matthew Johnson
http://www.matthew.ath.cx/