kicad-developers team mailing list archive
Mailing list archive
Re: IDL for DBUS
Dick Hollenbeck <dick@...>
Wed, 01 Apr 2009 06:51:20 -0500
Thunderbird 220.127.116.11 (X11/20090318)
Wayne Stambaugh wrote:
Dick Hollenbeck wrote:
Even though it never got much attraction, I do like this tool here,
and feel it would be a good tool to rely on if DBUS were to be added to
Kicad. The CIDL is cleaner than the "dbus introspective XML", yet a
person can generate the xml using this tool.
It looks like an interesting tool but I noticed that this project is not
being actively developed. I don't know if that will be an issue or not.
Not really. The tool also does not support structures yet. Designing
all the DBUS functions/methods without any structures as arguments might
be possible, but I suspect it would be easier to add the structure
support than to have every exposed DBUS method avoid them. However, in
D-BUS, methods can return more than one object or value, so this is a
philosophical thing to settle and decide about.
However, the tool is not as import as its input format. Its input
format is 98% for human consumption, not machine use. So I say, it is
a form of documentation of the APIs that we would expose for programmers
wishing to get at the document models, i.e. data trees like class BOARD,
within Kicad from outside of Kicad via D-BUS. This CIDL format is a
reasonable alternative to the "D-BUS introspective XML" for human
reading. Again, this is for human reading, and between the two, CIDL
is far more readable than XML.
This exposed D-BUS support within Kicad would be documented, using CIDL,
and would show up in a programmer's manual on paper, in a howto, or on a
website showing the objects, interfaces, and methods that are callable
within Kicad via D-BUS. Then, at runtime, this same information is
retrievable via the D-DBUS Introspector interface. However in that
context the information is returned in "D-BUS introspective XML"
format. Well its too late to really be optimally usable at that point,
you have to write a program to get this XML from the exposed D-BUS
support within Kicad, and then turn around and modify your program. I
am saying, do programmer's a favor, tell them about the exposed support,
but do it in a format that is human readable. Lastly, it is trivial to
convert from CIDL to the XML format that D-BUS exposes. It can be done
manually if needed.
Or a person could spend a few days polishing off the tool. At that
point maybe the D-BUS community would adopt it into their project. This
observation of mine is an opinion that many D-BUS programmers are likely
to share. I am not inventing problems, I am pointing them out.
I am thinking that reading XML files as a human is not fun.
I always thought XML readability has been over hyped. There are much
easier file formats to read. Try reading a ODF or DOCX file sometime
just for fun. Of course there are many that are worse.
<<< snipped >>>
The main point of the *.cidl files would be to *design* the interfaces
before coding anything. Also, this design would be valuable in any
future work within Kicad, if for no other reason than it would help with
the document existing and possible future document models.
I think this is the real strength of XML. It forces you to clearly
define your document model up front.
We are not designing an XML document, but exposing our "document models"
that exist within Kicad, such as BOARD instances, and schematic data
trees. I am saying that having the D-BUS access to them helps us
clarify the design of good access methods to these document models, and
this in turn can be used to fine tune the actual C++ methods within
these document models.
If you get that part right, your
code is usually fairly simple. I have use XML in a few Python programs
and the code to read and write the files was very simple. All of the
complexity was in the document definition. The parsers do most of the
heavy lifting. I hope whatever you implement you can make it stream
based so that it will be more flexible than the current FILE/fprint
This is something I am interested in. I also see it being dove-tailed
into a task involving a new file format and data tree for PCBNEW.
I may have some time later in the year to start this. I am currently
bringing a new ARM board to market that was designed with Kicad.
Sounds interesting. It's been a while since I've had to do any embedded
design. I live in an analog world now. Enjoy your ARM project and I'll
be keeping my eye out for that new XML code later in the year.