[dba-users] A call for review

[Andrew Jensen]

What I am about to put in this message will not be well received I fear, and some will undoubtably say that it is negative and mean spirited. To those that feel so, I assure you it is not my goal. A few months ago I started seriously investigating the use of OOBase as a development tool, not for personal use but to deliver applications to clients. It has become clear that the tool as it has been developed falls far short of being suitable for such purposes. I do not mean for this message to be taken as an attack on any one in the OpenOffice development group, but I also do not intend to mince my words. Before proceeding just one small bit of background. I am not a proponent of OpenOffice, it is a tool nothing more. I would like to see it have success for a number of reasons, one would be purely self-serving. I could use it as a means to generate income. For this purpose it is far from the only choice. The other reason is broader, I believe in the free market system and for that to work there must be competition. As I see it OpenOffice is the best postitioned office suite out there to give Microsoft a serious run for its money and if that could happen everyone would be better off. So what I have to say here is intended to help further that goal, please take it in that sense. Now for my main points. I fail to see how the current implementation of Base meets any particular users needs. It seems to be too hobbled, by design, for serious consideration as a development platform. It also seems to be too lacking in ease of use features to make it useful for the casual user. What do I mean by this? In the case of data enty forms management you have basically taken the existing Writer document as container for databae form controls, functionality, removed some of that functionality, or at least made it more difficult to get to, and moved the physical storage of the file into a databae file. What real benefit did this bring to either the casual user, or the databae developer. I will come back to this point later. Before I leave it however, I suggest you take a look at the number of people that have truly struggled with the simple task of opening a form from within a macro. It is far from just a matter of lack of documentation. A person has to understand not just the difference between a forms definition object and its instantiated object, but must have a good grasp of scoping issues within the Basic interpreter. Granted you can always just double click a form name from the GUI, but even realativly novice users expected to find the ability to designate a default form that would open when the database file is opened. A process that is not even easily performed via code. Because of this the users are already moving away from embedded forms and sticking with stand alone writer documents. Second is the issue of a report writer for Base. I will say this as simply and bluntly as I can. The wizard that is supplied is simply a poor replacement for a report writer. In reality this wizard supports one report layout, yes it can use a number of different character styles and you can choose between grahpics of coins, or litle stick men, but the basic layout of the report is the same. Beyond producing shopping lists I do not see how this was expected to fulfill the needs of a serious report writing tool. Granted in the case of external data sources one could use different report writers, but in the case of the embedded database, as of this moment, I do not believe there is any other choice beyond the report wizard. Third, script management. Given that the databse file does not support the attached basic library stucture that the other doucment types in OO do, and that attaching any macro code to form documents causes a conflict with the macro security module one is faced with always putting code into outside libraries. Another hurdle for the novice user, not much of a problem for the databse developer I would admit. However, there is another issue here. One can, as far as I can tell, only address forms from within scripts. Try to work on the rowset that is represented by opening a table directly and there seems no way to do so. This makes creating macros that would be truly useflul as a means of enforcing business logic rules on the data virtually impossible. Add to this the selection of a database engine that only supports stored procedures via creation of Java classes and you have effectively removed a sizeable number potential in-house developers. Then there is the issue of stability. My understanding is that release 1.9.130 is, or is very close too, the first release candidate for OpenOffice verison 2.0. If this is the case then there seems to be a serious amount of work left to do. Just today it became clear to me that the very first requirement of a database management system, as it pertains to the embedded database engine, is not being met. You must not, if possible, lose the data! I would refer you to new issue #54609, and my obsurd test that I recount at http://www.oooforum.org/forum/viewtopic.phtml?t=24043 . I call it absurd, because it should be clear that one record would have been enough, but the point is made quite concrete with a million. I want to put forward the proposition that the problem with Base lies not so much in the current code, but rather in the attitudes that went into developing the module itself. For this I point to a few items. First - From the database_application specification. Section 2 Motivation. The first paragraph is "One of the most annoying things is that people ask on the OpenOffice.org lists, “Does OpenOffice.org also support databases?”. This has been the case since the first release. The problem is that the database part of OpenOffice.org was not that intuitive to find and the approach of data sources was hard to understand. Another point is that the current implementation is too development specific resulting in the normal user not recognizing the intention of the links in a data source. This has to be changed." Second  - From the Embedded Database specification. Section 1 Motivation. The first paragraph is "The difference of database data and other database aspects like queries, forms, or reports is for the user often hard to understand that they are saved in different locations. If the database itself is not included in the file, the database application creates, it is always possible that the user forgets to copy the database as well, when he wants to e.g. send it via e-mail. Therefore the database application has to write the information about queries, forms, and reports but also the data if the user selects the embedded database as well." And Section 2 "An user scenario could be for example sharing database files, the description above is more a bug description." Then there is this from the a posting on the dba features mailing list, dated yesterday. "Technically, this new behaviour is an enhancement, since it introduces new functionality for this particular database type. To the user, it's the fix for a bug (which in fact has been reported several times in the Beta test), since s/he expects from OOo's pet database HSQLDB to offer the most basic "rapid database design" functionality." Am I reading these correctly, the main motivation was to get the users that where not smart enough too understand how a database server worked to stop annoying the support staff. Or is it that one should fix a bug that made it possible to forget to copy some files. Should I take it that this is not really a serious tool, the embedded database manger, but a 'pet'. IMO there is a trend here. There is a belief that what you had before was sufficient and what you are creating now is, well, not really worth the effort. It is with all earnestness that I ask you to think about this. Like it or not when you announced the inclusion of a database module in OpenOffice you created an expectation amongs new possible users. On this point I believe there may exist the largest problem of all. Who is the target user of a databae module. I don't believe it is the user that will put data into a data entry form, nor the user that will run the reports. Although, these will be the greatest numbers of persons. A database module will be fundamentaly different then say a word processer, where the focus of the application is the document and the primary user the person creating the document. IMO the primary user of the module will be in-house and third party database application developers, for the database is used to implement processes within an organization. Up till now, I believe, the focus of the datasource controls within OO have been to feed data into documents. Not used as a basis to build data validation and process mangement applications. But these are precisely the uses your competitors database is used for. Again look at the OOOForm postings, for every one person that is talking about a very limited, trivial database application, there is a good number talking about small office automation tasks. I personally have a hald dozen people on the board that have spoken with me in depth, off line, some even supplying there database files and requirments so that I might help them. These have been people expecting to find a database system capable of automating work processes within organizations ranging from 3 users to 9 users. OOBase as it is conceived is not capable of this without using an third party database engine, which I contend defeats the purpose of having it as a stand alone module in the first place. In closing let me say this. There will be a large number of people that will come and take a serious look at OO now, because of the Base module. Many if not most will be comparing it to MS Access, with this being the measuring stick I am afraid that  OO.o will not get a long review. I urge you to take the time to sit down, look at what you intend Base to be and who it's intended audiance is and then make these known to the public. For right now, what is being expected and what is being delivered are far from the same. Sincerely Andrew Jensen