Re: wysiwig TeX in dia

[James K.Lowden <jklowden speakeasy org>]

On Wed, 19 Jun 2002 18:48:54 +0200, "Cyrille Chepelov"
<cyrille@chepelov.org> wrote:

> > Also I would like to ask what do you think about using
> > a postgres database backend for your object? Like be
> > able to store all the diagrams in a database? 
> > via Perl::DBD we can hook in any database around.
> > Cool huh?
> 
> 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?

Cyrille, 

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.  

If several people can modify a diagram, I suppose up to a point they could
use CVS or even just NFS <shudder> to keep themselves synchronized.  But I
doubt the average Dia user is going to want to poke around in the diagram
file looking for CVS's

   <<<<<<< diagram.dia
       version A
   =======
       version B 
   >>>>>>> 1.6

messages. :)

The database's chief technical advantage is that each shape can be stored
separately, so people can work on different parts of the diagram without
getting in each other's way.  That doesn't avoid the need for conflict
resolution, of course: a whole subsystem of comparing/choosing/merging is
needed.  

Another advantage is reuse and reporting.  If you want to find all the
diagrams for clients A and C that use shapes having property X, it's
surely easier to write that query in SQL than C or even Perl.  

Naturally, a shop full of Certified Dia Professionals hammering away at a
giant collaborative diagram is light-years distant from the "average Linux
end-user".  That doesn't make it a bad or pointless idea.  

Primed with suitable relaxant, it's possible to imagine standardized
mapping of XML to relational databases, via a DTD->DDL XSLT.  From there,
a standard library that stores and retrieves XML documents using some
database driver technology.  Then, Dia (or any other XML-based
application) could have the option of using a filesystem or a database as
its data store.  That is, as long as the process of serializing the
diagram to XML is kept separate from the process of writing to the file.  

At least, that's how I see it.  

Regards, 

--jkl