On 10-03-2014 11:52, Counihan, Tom wrote:
Hi Folks,
I'm trying to understand more the technical details of crosswalk and come here
for some insight.
My query is specific to the use of these IDL files, and particularly the
workflow around them as a core developer would view them.
What triggered my query was this:
https://crosswalk-project.org/jira/i#browse/XWALK-889
So, in summary, I see a lot of these IDL files scattered across the code base
and I'm curious to their usage.
1. Are they used to auto-generate stub code, there after one develops against
those stub/skeleton?
a. If so - could someone direct me to the code generator?
2. If one finds the interface has to change, is the associated IDL
changed/patched first, and the ensuing generated code augmented to adjust to
the interface change?
3. Or is such an interface modification done at the code level, and the IDL
refactored to reflect what happens in the core code base?
I guess what I'm trying to figure out is the development flow - is it a classical
IDL-> code generation with round trip taking one back up to the IDL for each
change or is the IDL simply viewed as a pure spec and the incarnation of same
hand-cranked?
If there is any wiki page documenting this that I may have missed I'd
appreciate direction.
Hi Tom,
These IDL are used in the extensions implemented inside Crosswalk (so
far only on RawSockets and DeviceCapabilities).
The main purpose of these IDL is serialization code generation. We took
this mechanism unchanged from Chromium Extensions and managed to get it
working on Crosswalk. They are not WebIDLs and are very
Chromium-specific, hardly can be used outside the Chromium tree.
Two things are generated from the IDLs:
- Data structures. For example, the TCPOptions dictionary defined at
tcp_socket.idl generates a C struct.
- Data serialization code for sending these data structs from the
JavaScript part of the extension to the native side and vice-versa. It
is more effective and easier to use than JSON.
Overall, the IDL stuff helps, sparing us from a lot of boilerplate code.
But it is not a silver bullet. A lot of things have to be coded manually.
Chromium for instance generates most of the JavaScript part of their
APIs from these IDLs, but we could not use that due to the complexity of
our APIs. Chromium APIs have only static asynchronous methods, while
ours we sometimes have to create objects, sync methods, etc.
You might be asking why we are not using this on the external extensions
(plugins like tizen-extensions-crosswalk)? The main reason is it uses
non-stable Chromium APIs and Chromium data types. They change a lot and
we need to offer something stable to people developing extensions plugins.
A few technical references:
- The buildsystem is processing IDLs based on a rule define at
xwalk_jsapi.gypi. There you find links to the scripts generating the code.
- The IDL file xwalk/sysapps/raw_socket/tcp_socket.idl will generate the
code out/[Release|Debug]/gen/xwalk/sysapps/raw_socket/tcp_socket.[cc|h].
There you can see the amount of code it is saving us from.
Cheers,
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
