Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Michael, Others,

In our Compagny, editing house, we uses OO and LO as the one and only application. Base is here used as a frontend for getting data out of flat-text-datbases and MySQL. Data we need to produce documents in Writer, Calc etc... For producing reports we found ORB pretty stable, so please keep LO-Base-ORB at least at the current OO level
Thanks

Fernand
Hi Kohei,

On Mon, 2011-05-16 at 22:14 -0400, Kohei Yoshida wrote:
1. Promote the chart8 filter as the preferred filter for the
chart2.Document type.  This can be done by the attached
chart8-is-preferred-for-chart-document.diff patch.
        Patch looks great to me :-) can we get that into -3-4 and get some more
reviews for -3-4-0 ?

2. Remove the type detection definition for the chart2.Document type
from the report builder itself.  This can be done by the
report-builder-dont-act-like-chart-handler.diff patch.  This will
prevent ORB from advertising itself as the chart filter provider.
        Did you manage to play with the ORB chart feature ? I would strongly
prefer a potential, transient breakage there, than an ODF
incompatibility that will create broken files when we save ;-)

I think option 1 is pretty safe, but I don't really know if this would
cause any side effect in other, unexpected places.  For instance, the
latest ORB seems to claim some limited charting functionality, and this
may mess that up, or perhaps it may not.
        Well - it sounds like the ORB is pretty messy anyway :-) so ... can it
really make it much worse if it crashes the whole app left and right ?

My preferred option is option 3.  Because, while I was test-driving ORB,
it crashed several times due to null pointer exception from the Java
code.  And when it does that, it takes the whole soffice process down
with it.
        And for those complaining about the idea of removing ORB altogether:
doing some work to help out improve the stability of the implementation
sounds like it would be a good plan. Rather than just wishing it was
better, we need (new) developer resource applying to fixing it, with a
set of clearly filed and isolated bug reports - preferably with the Java
stack-frames that can come from the console (I think), and so on. If the
functionality is extremely sub-standard, and creates the risk of
data-loss for its users, then we may well want to disable it - or make
it 'experimental'. "just reverting a commit" is not an easy thing to do
- it requires first finding the problematic commit, also there are a lot
of interlocking pieces in most such piles of software :-) so again, real
developer resource is required: that can be grown out of sweat&  tears
from technical QA guys digging deeper - or preferably from interest from
those who most need / use the feature.

        ATB,

                Michael.



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.