On Fri, 2004-02-20 at 22:01 -0500, MenTaLguY wrote:
On Fri, 2004-02-20 at 05:41, Charles Goodwin wrote:
Inkscape is basically aiming in-memory hierarchical database, including transactions, which I think kind of precludes using libxml structures. Also, the eventual plan for Inkscape is to also store CSS parse trees in the same document tree as the XML document itself.
I'm unsure of the feasibility, but have you looked at Gnome-DB for doing this rather than implementing it over again?
Well, the goal for right now is a lot more modest than a general database architecture -- I'm just using database terminology with our parse tree representation because treating it as a (hierarchical) database turned out to have some conceptual benefits.
Conceivably, we might do some real database-y things down the road to support things like distributed editing, but that's a long way away yet...
Even then, I'm not sure GnomeDB would be a good fit, since GnomeDB is designed for relational rather than hierarchical data.
it is designed to cope with any data source, even with hierarchical data. There might be some stuff missing, but data models (recordsets) can contain fields of type 'list', which contain lists of values, and those values can in turn be more lists, and so on. So it should cope with hierarchical data also.
I'm not sure though if libgda is the correct solution for inkscape XML parsing.
Also, there are some special requirements, like a commit operation that returns a log fragment which later can be rewound/replayed to undo or redo the transaction (this is used for undo/redo of operations that affect the parse tree), and fine-grained constraints and change notifications.
this is already available in libgda in the form of transactions. A XML provider (= plugin) could be implemented, and have it implement the transactions internally. In fact, we already have a XML-based provider, although it is supposed to only support libgda's export/import XML format (a DTD we've got to describe a full database).
cheers