23
edits
Firefox/Feature Brainstorming:Add-ons, Platform Development: Difference between revisions
Jump to navigation
Jump to search
Firefox/Feature Brainstorming:Add-ons, Platform Development (view source)
Revision as of 08:45, 13 April 2007
, 13 April 2007→Add-ons/Platform development
(→Add-ons/Platform development: javascript multithreading) |
|||
| Line 145: | Line 145: | ||
</td><td> | </td><td> | ||
n/a | n/a | ||
</td></tr> | |||
<tr><th colspan="2">XULRunner/libxul</th></tr> | |||
<tr><td> | |||
;Freezing ABI | |||
After we compiled xulrunner 1.9a3 and rebuilt our xul application against its libraries, all idl-derived @UNFROZEN interfaces are perfectly available. The xpcom interfaces are c++ classes with no data and only pure virtual members. Member calls use offset of a class pointer, not symbols. So it doesn't matter whether they are exported or not, as long as nsComponentManagerImpl provide those pointers. The former xulrunner was 1.8.0.11, which is several _years_ older than the latter. This underlines tremendous resilience of the XPCOM. | |||
The current mantra of XPCOM usage is "DON'T ever use non-frozen interfaces". It seems too tight. Only one of the long list of [http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html#AEN135 ABI breaking techniques] pertains to the XPCOM: c++ #2 - add or remove virtual member functions. However, according to c #2 of the same article, the library can append any structures it allocates. A c++ vtbl is just like any structure, and in XPCOM terms allocating means implementing. | |||
If the above is correct, the XPCOM can raise a new flag:"just don't IMPLEMENT non-frozen interfaces from c++". This will add three restrictions the XPCOM side after a release: | |||
*all callback interfaces need to remain stable; | |||
*non-callback interfaces may only be appended; | |||
*or release a new version. | |||
</td><td> | |||
</td></tr> | </td></tr> | ||
</table> | </table> | ||