Changes needed for "LibreOffice 4"

[Michael Meeks]

On Fri, 2012-07-20 at 19:59 +0200, Lubos Lunak wrote:
>  By the way, could somebody please confirm this or list the things where we do 
> need to care about stability to the outside world? I know ure/source/README 
> has a list of libraries, but this is not only about libraries.

	In the worst case, documents contain StarBasic macros that do the
oddest things using the most tangled UNO APIs you can think of :-)
Including FooInterface7 - the 7th attempt to get it right, highlighting
again the lack of a need for fundamental extensibility ;-)

	The IDL is also compiled into JAR files that are necessary to link Java
plugins; configuration keys are also part of the ABI; and ideally the
behaviour is also predictable.

	Of course, most of this is a myth; the chart2 re-write had some very
substantial changes to the UNO object model built-in, and IIRC almost
no-one complained: then again chart2 was much prettier than chart1
so ... perhaps that's why.

	The real problem is, that there's no good way of telling what UNO / C++
interfaces people are actually using in their binary / proprietary
extensions. Unfortunately (apparently) there is no signature that we can
unwind from use of an interface - though that could be altered for the
future. That result still amazes me - surely there is some in-lined
class / type information somewhere. Eike's idea of running 'strings' on
a few binary exensions seems like a great one - if we have a bazillion
duplicate ::com::sun::star's in our binaries, surely others must have
been infected too ;-)

	Then again - how much sympathy for the proprietary world we should have
is unclear. Then again - some binary proprietary plugins are
indispensable to some segments - eg. Quebec has some great French /
grammer checker to help those french-as-a-second-language writers, or in
Germany the Dudencorrector seems popular etc. etc.

	But - yes, getting hard numbers; and better hard lists of which
interfaces are actually used out in the wild would be awesomely useful
when making this sort of decision :-) Any help collecting that is -much-
appreciated.

	ATB,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot