Re: [Inkscape-devel] Joining GNOME Office
- From: Rodrigo Moya <rodrigo gnome-db org>
- To: MenTaLguY <mental rydia net>
- Cc: Charles Goodwin <charlie xwt org>, Inkscape ML <inkscape-devel lists sourceforge net>, Gnome Office <gnome-office-list gnome org>
- Subject: Re: [Inkscape-devel] Joining GNOME Office
- Date: Mon, 01 Mar 2004 11:11:55 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]