B2G/Architecture: Difference between revisions

No edit summary
Line 229: Line 229:


== Gecko: DOM APIs ==
== Gecko: DOM APIs ==
"DOM interfaces", approximately, are how web content communicates with Gecko.  There's a lot more to the DOM than that, but the longer discussion is beyond the scope of this document.  DOM interfaces are defined in [https://developer.mozilla.org/en/XPIDL IDL], which defines both a foreign function interface (ffi) and object model (OM) between JavaScript and C++.  Again, there are more details that could be discussed here which are beyond the scope of this document.  Let's learn a bit of IDL by example.
The very simple vibration API is exposed to web content through an IDL interface.  That interface is [https://github.com/cgjones/mozilla-central/blob/master/dom/interfaces/base/nsIDOMNavigator.idl#L66 here]
<pre>
  [implicit_jscontext]
  void mozVibrate(in jsval aPattern);
</pre>
The <code>jsval</code> argument indicates that <code>mozVibrate</code> (our vendor-prefixed implementation of the vibration specification) accepts any JS value.  Details of working with jsvals are beyond the scope of this document.  The IDL compiler generates a C++ interface that's implemented [https://github.com/cgjones/mozilla-central/blob/master/dom/base/Navigator.cpp#L657 here]
<pre>
NS_IMETHODIMP
Navigator::MozVibrate(const jsval& aPattern, JSContext* cx)
{
  // ...
  hal::Vibrate(pattern);
  return NS_OK;
}
</pre>
There's quite a lot of code that's hidden here by the ellipsis ("..."), but let's ignore for it now.
The call to <code>hal::Vibrate()</code> transfers control from the DOM to hal.  From there, we enter the hal implementation discussed above.  A key point to note here is that the DOM implementation doesn't care what platform it's running on (Gonk or Windows or OS X or ...), nor does it care whether the code is running in a "content process" or the Gecko "server process".  This is all left to lower levels of the system.
Confirmed users
699

edits