Michael 'Mickey' Lauer wrote:
Hi Didier,
>
thanks for the update regarding your developments -- it's much appreciated,
especially for the folks who can't hang around on IRC 24/7 ;)
Yesterday, i was working on QT4 bindings (at least give it a try), as
i went through the FSO DBUS specs, some questions start rising in my
heads. Of these questions some are related to what's being discussed
in this thread, so here i am! :)
Thus it can easily be built as part of OE. If one feels like cooking a
recipe for it (and vala-dbus-binding-tool) that would be super cool!
If no one beats me to it, I'll do that.
1) Enumeration values:
...
<interface name="org.freesmartphone.Phone.Call">
...
<method name="GetStatus">
<arg type="s" name="status" direction="out"
fso:enumeration="org.freesmartphone.Phone.CallStatus"/>
</method>
...
</interface>
<fso:enumeration name="org.freesmartphone.Phone.CallStatus">
<fso:value name="ready">READY</fso:value>
...
</fso:enumeration>
Looks good to me. This only refers to string-enumerations, right? I'm all for
that, since I don't think int enumerations make much sense over dbus --
Why do you think so? Enumerations being a set of predefined values, i
don't see the point to send strings over DBUS, using integer constants
means less overhead in DBUS and in the clients as well, it is far less
CPU consuming to compare integers than strings.
Or perhaps i missed something...
For example GSM.SIM.GetAuthStatus() can return 5 status, why not
encoding these 5 possible cases into int enumeration, it would be
better to be able to compare status again the int value SIM_READY than
the string "READY"
however, perhaps we should encode a type entity here from the start to support
folks that have special needs:
<fso:enumeration type="string" name="org.freesmartphone.Phone.CallStatus">
2) DBus errors
...
<interface name="org.freesmartphone.GSM.Device">
<error name="NotPresent"/>
<error name="Timeout"/>
<error name="Failed"/>
Ok. Although for clarity we perhaps should make this <fso:error>, since it's
not a part of the standard XML introspection notation (which is a crazy
omission, but anyways...).
...
<method name="SetAntennaPower" fso:throws="NotPresent, Failed">
I wonder whether we need to have this in the method specified, rather than just
documented. Do we gain any static testability from it?
For C++, it can be useful as function members can have a exception
specification like:
void SetAntennaPower(bool antenna_power) throw(NotPresent, Failed);
3) Transparent proxies
...
<interface name="org.freesmartphone.Phone">
...
<method name="CreateCall">
<arg type="s" name="number" direction="in"/>
<arg type="s" name="protocol" direction="in"/>
<arg type="b" name="force" direction="in"/>
<arg type="o" name="call" direction="out"
fso:type="org.freesmartphone.Phone.Call"/>
</method>
<signal name="Incoming">
<arg type="o" name="call"
fso:type="org.freesmartphone.Phone.Call"/>
</signal>
</interface>
Can you elaborate on that with an example?
For what i understood, in that case fso:type tell you the "main"
interface implemented by the object in question.
The problem could be that as (all)most all objects in fso implement
several interfaces, this attribute tell you only about one of the
implemented interface.
Regards,
Chris
Thanks,
:M:
_______________________________________________
smartphones-standards mailing list
smartphones-standards@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
_______________________________________________
smartphones-standards mailing list
smartphones-standards@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
