First comment: Take a minute to read the XLink specification. You'll find
it helpful in understanding the sort of capabilities we want to support.
On Sat, 5 Aug 2000, earth wrote:
> Current Purpose: A database and supporting API which takes incoming
> documents, checks them for links to other documents and inserts
> any found links into a database in order to enable 'back link' maps,
> trees, or diagrams.
More generally, we want to support extended link groups as defined by the
XLink specification, which allows us to support back links. We also need
to support link types.
Also, we want a layer in our system that can add links to a document. For
example, we should be able to write a module for linking requirements
documents with Use Case documents automatically.
> 1) I wondered at the last meeting and then again when i was thinking of
> this what the plan is for whether to require a database server for
> all installations or whether the plan was to -not- require a database
> server for any installation? One way to go is to require a db server
> but to write a series of bridges for different SQL servers .. pick a couple
> initial customers and make the system work for them with the idea
> of writing a generic enough interface to allow for more. I use
> mySQL on many projects, but oracle and microsoft SQL seem like
> obvious candidates.
My cop-out answer is, initially, we should use whatever suits our needs
best. In other words, it's something that fulfills the software's
requirements, it's something that's freely available, and it's something
that we can quickly and easily integrate into the system. I think a
MySQL-based solution is fine in this regard.
However, at some point, we need to think a lot harder about this
question. Maybe it will be worthwhile to write some kind of
object-relational layer that works plugs into any relational database. Or
maybe we'll want to use an XML database like Ozone-DB, which came out of
Stanford. Or maybe we'll want to write something like what Cliff Joslyn
proposed two weeks ago, a storage system that does not use the relational
ontology but instead something that is better suited for the types of data
structures that we'll be dealing with. (Disclaimer: I missed Cliff's
talk, and only had a chance to chat with him briefly afterwards, so if you
want a more detailed description of what he was proposing, you'll have to
> OR does this system need to include whatever DB its going to use
> within the package itself? (simplifying the installation in many cases,
> but weighing the system down).
I don't think this is necessary for initial releases. Eventually (say one
or two years down the line), if someone wants to develop an out-of-the-box
solution based on the OHS, then this will probably be necessary.
> let me know if this is at all useful.
Very much so.
-- +=== Eugene Eric Kim ===== firstname.lastname@example.org ===== http://www.eekim.com/ ===+ | "Writer's block is a fancy term made up by whiners so they | +===== can have an excuse to drink alcohol." --Steve Martin ===========+
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:49 PDT