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.
