On 10/21/2011 10:39 AM, Michael Meeks wrote:
Hi Kevin,
On Thu, 2011-10-20 at 20:06 -0400, Kevin Hunter wrote:
From the wiki page, one of the concerns is "binary incompatibility". I
assume this is in reference to extensions?
Sure; of course we only export a reasonably small ABI, the 'ure' (big
chunks of which are in-lined C++ methods that call SAL_CALL C functions
that we havn't changed and should cross-compile nicely). The
C++ helper classes (it is hoped) due to windows direct linking, and a
different ABI anyway shouldn't conflict.
My hope was(is) that UNO can shine here (with some tweaks) as a
bridging technology between the ABIs - at some fairly minimal
performance cost. At least, given Stephan's expertise& a little
testing, it "might just work". That would of course mean shipping some
duplicate legacy MSVC++ compiled libraries, but ... surely do-able.
It would not suffice to ship them, one would also need to build them.
Kind of back to square one.
Question: is there merit to moving toward an enforced sub-process model
for extensions ?
It is an interesting idea; of course in theory UNO makes this easy, in
reality - I would scream and run away from cross-process component
usage. Debugging reference leaks / cycles / etc. is bad enough
in-process, never-mind cross-process; or worse between many (external)
components.
Note that freshly installed extensions *are* routinely loaded off to an
external uno process.
-Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
