odeviced: Progress report

[Guillaume Chereau]

On Wed, 2008-05-28 at 14:14 +0530, Sudharshan S wrote:
> As per my understanding, using vala removes the need for
> dbus-binding-tool to process interface xml files. So there isn't any
> org.freesmartphone.Device.xml.
> Isn't an xml interface file required to generate the docs?.
Yes, but I would like to have a precise explanation on all those
different files (someone should put it on the wiki)
As far as I understand (by looking into the specs project), we have :

- xml.in files, that are in a format originally created for the glib
project. They describes all the interface and the documentation for it. 

- the xml dbus introspection files. They are in the format described by
the d-bus introspection interface specification. I think those files are
actually not needed.
You can use it to generate a C code skeleton, but since you use vala you
don't need that indeed. The thing I am not sure is if this file is used
by the dbus daemon (like : all the interface files have to be installed
on a specific location on the computer and the daemon can check that the
call you make to a d-bus service are coherent.)
Those file can be generated from the xml.in file.

- Then we also have docbook format file (it is also xml.) Those files
are generated from the xml.in files, using a xsl file :
The xsl file has some information at the beginning :
<!--
     Convert D-Bus Glib xml into DocBook refentries
     Copyright (C) 2007 William Jon McCann
                   2008 Harald Welte
     License: GPL
-->

- Finally we also have hxml files, generated from the docbook files. OK
this step is well known. Once you have a docbook file you can convert it
into any other formats.

So to auto generate the doc you need this "xml.in" file.

What I would like to see is a program that can process python or vala
code and generate this xml.in file, and it has to be able to read the
doc comments of the code as well.
If it doesn't exist I think someone could write a small python or perl
app to do so (I wouldn't like to be this guy though :-) )

> 
> As for the plugins, the service just looks if they have <plugin>_init in
> their sources. The DBus interface (or even lack of) which they export
> are upto the plugin writers. I would like to have comments on this.
> The current logic is pretty simple but at the cost of looking like a
> hack IMHO.
> 
> Using GTypeModules in the code brings in a cozy dynamic typing mechanism
> for the plugins. But it means more boilerplate code for the plugins.
> Something which I find to be less appealing. Most Gnome apps use
> GTypeModule to wrap up GModule instances. Something similar to the
> plugin class present in plugin.vala.
> What do you guys think? To GTypeModule or not to GTypeModule?
I can't help you here. I have no experience of this kind of problems.
What I would do is : do it with GModule interface for the moment. Then
when your code become unmaintainable, rewrite it all :-)

> 
> > Another thing : I don't know how difficult it should be, but would it be
> > possible to add a "simulated" option to some of the devices, so that we
> > can test the software on any computer ?
> >
> 
> Cool. For things like wifi plugins you could run odeviced as it is. But
> yes, since FreeRunner has special devices adding a simulated option
> makes sense. Especially for GPS and friends.
> Maybe add a --simulate=<plugin> or even --simulate command line argument?
Yes, or a "simulated = True" line in the conf file.

- Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxtogo.org/pipermail/smartphones-standards/attachments/20080528/85bfda13/attachment.pgp>