Re: OK to merge the fw? libraries in framework?

Hi Mathias,

        First - thanks for your input ! :-)

On Wed, 2012-02-08 at 23:56 +0100, Mathias Bauer wrote:
> Indeed. You should be prepared to have fun. :-)

        :-) all LibreOffice hackers are prepared to have fun :-)

> First we wanted to have two libraries: one for GUI related code that
> needed to link against vcl, then another one that doesn't. That's "fwk"

        Thanks for the explanation. It seems that loading a writer document
gives us: 'fwk', 'fwi', and 'fwe' but not 'fwm' and 'fwl' - so prolly it
makes sense to merge only the ones used at startup.

        IMHO the split of GUI code from non-GUI code here would be quite
reasonable if we had a consumer for that. It seems to me that all
headless uses of the code-base end up linking VCL and re-using chunks of
the toolkit anyway though so ... perhaps this was a step to a goal that
was not reached ?

> All in all I don't think that keeping the libraries separated is
> necessary, perhaps it's just confusing without providing any real
> benefit. OTOH changing that needs some work and bears the risk of fixing
> "interesting" build problems. But maybe you are lucky. ;-)

        :-)

> Besides that, I think that the performance gain by merging libraries is
> highly overestimated and I doubt that it is worth the penalties you pay
> for it (larger build times, eroding structures). I know that you have a
> different opinion about that, but IMHO the time and effort could better
> be invested into more componentization and keeping unnecessary code from
> being loaded at startup time.

        This is one of those multi-factor problems that changes with time of
course. The Mozilla guys - who have put a ton of time into startup
optimisation on both large devices, and also tiny handheld devices, and
whom, we interact with quite a bit (they're further ahead in finding the
pot-holes) merge virtually the whole browser into one shared library -
to save cold-start seek overhead on load, and of course linking overhead
on link. Also, if we really want to get good link-time optimisation
behaviour the more code that the linker can see, and better hide inside
one big library - the more we win.

        Worse than that, for the iPhone, I believe we are doomed to needing a
single-monster statically linked blob :-) which sounds even more
interesting, we've done some chunks of work to move there
(dis-ambiguating the component_ symbols eg.).

> Also besides that (as Tor mentioned the Android port), I'm pretty sure
> that nobody will ever want to use LibreOffice or any application of that
> kind and size on Android devices - for several reasons. I'm working on
> mobile apps right now (not only but also on Android), and so I'm bold
> enough to claim some knowledge and expertise.

        It's certainly interesting to hear your view, and I appreciate your
insight :-)

>  Mobile apps need to be designed to fit the platform requirements
> from scratch. This is not limited to UI (though this is an important
> part), but also covers workflow, security requirements and more.

        Sure; but the opportunity to re-write a new version of LibreOffice from
scratch on each platform is not such an attractive one either :-) And
bear in mind we're targeting initially tablets, and when tablets look
like this:

http://www.techradar.com/reviews/pc-mac/tablets/asus-eee-pad-transformer-954145/review

        And have dual-core GHz ARM CPUs (or even beefy Intel CPUs). That can
make it hard to conceptually separate the segment from a 'netbook'. Of
course, LibreOffice on a phone form-factor in it's current state is
unrealistic.

> Nevertheless the Android port is a wonderful engineering success and I
> admire the effort and the creativity that went into it - from a hacker's
> perspective, not from a potential users perspective. Of course I hope
> that you will prove me wrong. :-)

        Lol :-) so - there may be a lot of truth in what you write; and many
ambitious hacking projects fail. My hope is that, whatever comes out of
this we end up with a smaller, leaner, faster, better, more
cross-compile-able LibreOffice that wins in whichever segments are most
relevant :-)

        All the best,

                Michael.

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