It was discussed when Crosswalk Extension framework implemented. Internal extension does has, please look at the genapi_idl rule in src/xwalk/xwalk_jsapi.gypi. I do no know how much that generator can help.
For external extension(tec), so far there is no such generator. Thanks, Halton. From: Wang, Peter H Sent: Friday, April 11, 2014 2:01 PM To: Huo, Halton Cc: [email protected]; Christiansen, Kenneth R; Kostiainen, Anssi; Poussa, Sakari Subject: FW: why "xwalk.experimantal" ? (sysapps API implementation not comply with idl rules) Hi, Halton, Sorry. One more question. Do we ever had a plan or discussion to implement a tool to generate extension binding part automatically from WebIDL? In that way, we even don't need to run test to confirm our implemented API is complying W3C definition or not. Thank you very much. Peter Wang From: Wang, Peter H Sent: Friday, April 11, 2014 1:43 PM To: Huo, Halton; [email protected]<mailto:[email protected]> Cc: Christiansen, Kenneth R; Kostiainen, Anssi; Poussa, Sakari Subject: RE: why "xwalk.experimantal" ? (sysapps API implementation not comply with idl rules) I see. Thank you very much. From: Huo, Halton Sent: Friday, April 11, 2014 1:05 PM To: Wang, Peter H; [email protected]<mailto:[email protected]> Cc: Christiansen, Kenneth R; Kostiainen, Anssi; Poussa, Sakari Subject: RE: why "xwalk.experimantal" ? (sysapps API implementation not comply with idl rules) Hi Peter, There was a discussion about the namespace of SysApps API between Annsi, Sakari, Xiaodan, Hongbo and myself. The decision is we use nampspace xwalk.experimental. Following refer the quoted part from Anssi. To keep your JS code compatiable, I'd suggest to use code like var system = navigator.system || xwalk.experimental.system; system.getCapabilities(); [quoted From Anssi's reply] > Re the namespace, to follow the Chromium conventions you'd expose this via > xwalk.experimental.system.* > > You may also want to add an example or two to the spec, e.g.: > > navigator.system.getCPUInfo(function (cpu) { > console.log('The current CPU load is ' + cpu.load + '%'); > }); > > (Optimally this feature would be kept behind a runtime flag instead, and > exposed on navigator.system when the flag is turned off, but given we don't > yet have support for runtime flags in Crosswalk xwalk.experimental.system.* > is ok.) > > The API design is probably not optimal still, but shipping something as an > experimental features helps us gather developer feedback and iterate on our > implementation and spec. [quoted] Thanks, Halton. From: Crosswalk-dev [mailto:[email protected]] On Behalf Of Wang, Peter H Sent: Friday, April 11, 2014 11:19 AM To: [email protected]<mailto:[email protected]> Cc: Christiansen, Kenneth R Subject: [Crosswalk-dev] why "xwalk.experimantal" ? (sysapps API implementation not comply with idl rules) Hi, all, I'm investigating bug XWALK-889<https://crosswalk-project.org/jira/browse/XWALK-889>. It reports, when we leverage a framework to test if our implemented sysapps API comply the W3C WebIDL definition, all cases are failed. By my investigation the cases are OK. The root reason is pretty straightforward, for now, we bind all extension objects to "xwalk.experimantal.***" rather than "window.***" as the W3C WebIDL document described. I'm not familiar with the original design of our extension mechanism. I'm wondering, binding extension objects to "xwalk.experimental" is a transitional strategy or intended design? If it's a transitional strategy, then, maybe, we should ignore those failed cases. If it's an intended design, maybe, we should change the WebIDL description used as the standard to test. I'd like to hear your comments. Thank you very much. Regards, Peter Wang
_______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
