Hi Andrew, > It strikes me that there is no real way to answer these questions. One > reason being that there is no openly available statement of purpose for > this project. No where have I found a reference to a use case for > different users or uses of the package that clearly says: This is who > the targeted user of an embedded Base file is, and this is the expected > uses they would put it to. > > Now I doubt that this is really the case, that there is no idea of what > the goals here are, or as to who the target user(s) are for the Base > module. But I am left to wonder about it quite honestly.
We always try to evade those questions, that's why you don't find answers anywhere :) Okay, seriously (and yes, this is something which should be on the site, not in mails, but ... maybe I don't do this because my English is too poor to find a good sentence which can be sold as "Mission Statement"): The step we made with 2.0, with introducing all-in-one files, was targeted towards the small to medium SOHO use cases (I don't know whether this term is just marketing slang or used in the real world, it stands for "Single Office / Home Office"). The idea is that those uses cases can be found in a lot of environments - you'll always find small groups inside small/medium/large organizations which solve their local problems using an MSA-based database-driven application. That's where we want to be. This basically holds, this is still the main area we want to address: keywords are "small to medium", and "database-driven applications". However, this is complicated by the fact that there are too many people saying they use Base as front-end for server databases, and that it does a reasonable or even good job there. We can't simply ignore this part, which for a long time has been the only focus, of Base's identity. So, we end up with the balancing act you surely already noticed in my answers :) - it's an "on the one hand .... on the other hand" thingie. > This then brings the goals and the requirements coming in from the users > together. Only by having a well defined set of user classes and use > cases for those users can you actually decide what appropriate solutions > are to users requests for fixes, enhancements or features, and what > emphasis to give these requests in relation to targets and goals. I fear the above is far from such a clean definition you request here, but it's the best approach I can give you for the moment. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
