Le Wed, Jun 19, 2002, à 09:24:12PM -0400, James K. Lowden a écrit:
> > From a DBA's point of view, probably. From mine, not at all: handling a
> > Postgres database is totally out of possibility for the average Linux
> > end-user. Now, keep in mind we also have Win32...
> >
> > What's wrong with storing a diagram per file?
> The primary advantages of storing a diagram in database become apparent
> when the diagram is subject to collaborative simultaneous use. That's why
> CAD and Information Engineering systems offer RDBMS back ends.
[snip]
Oh, I see. You want to turn a core full of the assumption that it owns the
diagram and all its subcomponents, into a core paranoid about
externally-triggered changes. This looks like every possible thing but a
trivial undertaking in my book (about like transforming a simple diagramming
tool into a CAD package, probably...).
I can see good reasons for implementing what you describe, but it's
definitely not a "simple Perl::DBD hack job". IMO, a much more efficient and
generally useful thing to do would be to extend CVS so that instead of using
diff/patch/vi on XML files, it would perform the equivalent xml-aware
operations (ie, diff on a pair of XML trees rather than diff on a pair of
gzipped files; an XML patch which would be able to locate a specific node in
a potentially slightly different tree, and would apply the change; and an
XML "conflict resolver tool" which would take the "tree-with-conflicts" left
by the XML patch and allow the user to graphically resolve the thing.
-- Cyrille
--
Grumpf.