Hey Fernando,
I apologize if my message came across as a flame. That definitely was not my intention. I was simply in a hurry and foolishly typed a message that I readily admit was extremely poorly worded. What it should have said is more like this.
In the very early days of dbXML when it was just Tom and myself working on the software, and virtually no one using it, we made a decision to not expose binary content through the APIs. This decision was made to keep the software simple and focused exclusively on the XML domain. Now that the project has grown and other people are involved, it may be time to reconsider this decision. Before making that decision however, I feel that the use cases should be examined and that we should be sure there is real value beyond just using the file system. The XML:DB API already defines a BinaryResource type and as Tom mentioned the core also already supports binary. So implementation should be relatively simple should we decide to do so now.
After I read my original message on the list I had a feeling it would be taken the wrong way. I'll try to remember to not post when I'm in a hurry.
:-)
On Wednesday, June 26, 2002, at 12:42 PM, Fernando Padilla wrote:
Alright, I'll try to respond to this now. I tried to keep the flame down to a minimum, but I kept getting dumbfounded at the idea that a proper data storage mechanism shouldn't maintain binary content. Looking over what I just wrote, I guess the core of this is, if you're willing to use two disparate datastorage schemes/systems/servers to maintain the data for one system. I don't think that's an ideal solution, even if one of those systems is a filesystem.
The reasons for using a database in general ( xmldb, xindice, sql, etc ), over any other means of storing data are:
atomicity distributability transactions optimized querying
A filesystem doesn't provide any of these services. Yes we could write the code or layer systems to give us these features as we need them, but why, Xindice already supports most of this out of the box. The whole purpose for Xindice is to provide these services. Yes it's querying capabilities have been optimized and geared for XML based content, but that should not limit it's feasibility and usability as a data storage mechanism for the whole system.
I demand consistency: one system, one datasource.
I don't understand how if this is an option, you'll opt for anything else...
alright, so comments anyone?
so I vote +1 for Xindice to support the BinaryResource code. I don't think Xindice is a viable professional tool without it. If anyone knows how to do this, please submit the patch. :):) thank you
Fernando
On Fri, 21 Jun 2002, Kimbro Staken wrote:
It was actually an explicit decision not to expose this. It was one of
those things where you have to ask is it really necessary? At the time the
conclusion was no it wasn't. What are the major use cases where this is
necessary? What is the value add over using the file system? If we have
good answers here then we certainly could expose the binary functionality.
The XML:DB API does already have a BinaryResource concept, we just don'
t
implement it.
Kimbro Staken Java and XML Software, Consulting and Writing http://www.xmldatabases.org/ Apache Xindice native XML database http://xml.apache.org/xindice XML:DB Initiative http://www.xmldb.org
