On 3/26/13 3:35 PM, Fernando Cassia wrote: > On Tue, Mar 26, 2013 at 9:52 AM, Rob Weir <robw...@apache.org> wrote: > >> My ordered preference would be 1, 3 > > > yeah, great *sarcasm*, let's add another bullet point to a microsoft > presentation titled 'how Microsoft Office is better than > OpenOfffice.org".... OO.o lacks database? check!"
I don't see any sarcasm here but a valid order to address this problem. Do we really want compete with MS? Or do we want provide an open source and open standard based office productivity suite that can do most of the daily tasks of common users of such an office suite? I personally think we want the second and want help people who are open minded to solve their problems first and want to save money for other things. If MS is better in certain areas users have to ask if they need it and if they depend on the feature. In case of companies it always possible to have a mixed deployment of 95% OpenOffice and 5% percent MS Office or something like that. We are a very good and high quality alternative but not always a 1:1 replacement. It really depends what you have to do. I personally can live perfectly with OpenOffice. > > My opinion is that maybe Sun put HSQLDB in there to fill in the need for a > resident database engine, which in the commercial offering (StarOffice) was > filled by Adabas D. > > One can still read the positive reviews of StarOffice where the database > module is praised: > > http://www.amazon.com/Sun-Microsystems-0614647643195-StarOffice-7/dp/B0000DG2N4 > > //// > * StarOffice Adabas (database application) is included (getting MS Access > requires buying MS Office Pro) and is easier to use than MS Access. Adabas > integrates with other StarOffice apps so, for instance, users can easily > create mail merge documents. > /// > > So, if HSQLDB is not up to par, maybe the realistic solution is to find a > database engine lightweight and powerful enough to take the role that > Adabas D had in StarOffice?. > > FC > PS: I read this whole thread as 'we don't want to maintain this code, since > we don't understand it, and we fear it's buggy'. But the solution in any > case is replacing the database module for another, or improving the > existing code, not making excuses for saying 'people don't use databases > after all so it should be gone'. > nobody said we don't want, the key point that nobody worked on it, nobody maintains it, does improvements etc. We see of course demand for it but on the other hand we also see that it makes only sense with some degree of quality. Everything else can be more damaging for the project at all. I think it is not so hard to understand that a project driven by volunteers need volunteers for the certain areas or code get unmaintained, unstable, buggy over time or lacks for certain features and improvements ... Juergen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
