[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: wysiwig TeX in dia



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.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] Mail converted by Mofo Magic and the Flying D

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

GuideSMACK