At 05:20 PM 5/04/2003 -0500, Paul Schmidt wrote:

>It's like operating systems, we need to decide what needs to run in kernal
>space (or db engine space) and what needs to run in application space.
>For example can we store XML as a blob, suck it out of the database, run it
>through a parser in the application, add in any other data that is needed
>using standard SQL, and the format it to output?
>
>In other words can this be accomplished outside of engine space? I think it
>can, so it belongs in application space. Now we may be able to make this
>easier, by adding another blob subtype for XML as a hint to the application
>that this is an XML document your using.

We can do *much* better than all this - via blob filters. I make it
plural, because I don't think it's going to be a case of "one size fits
all". For example, standard XML may be too limiting and we'd want to have
a SGML filter too; and XHTML and ....

One of the traps I see with locking XML storage into the engine is that we
get stuck with something that's certain to be deprecated pretty soon, when
the next wave of *ML becomes the currency of the day. That's without even
the sticky mess of providing language and probably other internal module
support for yet another level of parsing.

> Some features would be nice anyway,
>like the full text search, but we have to be careful that we don't add a lot
>of baggage to the engine.

It's debatable how doable an internal FTS would be, anyway. One of XML's
features is that the data are stored in Unicode. Consider the casting
complications we already have with character set management...

>Firebird currently has a nice balance between
>engine size and feature count, lets not upset that balance.

Agreed - I'm all for XML support but let's give earnest consideration to
doing it from the outside, as with encryption, replication, et al. With
open source, we have no *need* to lock these modular options into the
engine. Applications are plugging into XML from many different
directions. Let's blaze the trail, be a Genuinely Modern Database Engine,
and focus instead on an excellent interface for plugging in optional modules.
-----------------------------------
These cross-threads are a PITA.
Could we PLEASE decide whether this thread belongs in Firebird-devel or
Firebird-Architect? I vote for Architect, considering that devel needs the
space for beta stuff right now.
-----------------------------------
Helen