Alright Tom. So I guess it wasn't as easy as we were led to believe by your last email.
But minimal support like this would be better than none. +1 Let me get this clear: When I ask for a Resource the client side has to return either a BinaryResource or an XMLResource(so we can cast it), the client side has to know which class to return doesn't it? So the backend should be able to differentiate between the two data resources.. But from what you describe below, the backend can't know this? So in all reality, the client side can't know this.. So you're proposing is that the client side will look at a flag at the collection level to know what kind of Resource to return... right? So that's just the makeshift solution.. I have another question. Which version of Xindice will we be able to break things to fix things? Like the UTF-8 patch, that somepeople were scared to check in because it would break old installations, and doing the proper BinaryResource patch, which would break old installations, but fix all new ones... On Fri, 28 Jun 2002, Tom Bradford wrote: > On Thursday, June 27, 2002, at 02:51 PM, Francesco Bellomi wrote: > > I would rather see binary as lower level than xml, not the other way > > round. Xml itself need to be ultimetely encoded in some binary form > > (such as UTF-8) to be written on the file, whereas encoding binary as > > (base64) xml is a less-than-optimal solution for both space and time. > > Ok... so here is the issue with binary resources in Xindice, and > hopefully this will allow people to think of it from an implementation > perspective rather than a knee-jerk 'we need this' point of view. > > Support for binary resources would *not* be as easy as everyone says it > would be for one very simple reason. When you mix and match tokenized > document streams (which is how documents are represented inside of > Xindice, and not as text) and binary streams in a single collection, you > open up the possibility for major data corruption when people start > reading/writing the binary image of XML documents directly (accidentally > or not) or when you try to read/overwrite a binary resource as if it > were a document. > > There are two solutions to this, the first is to have a special > signature at the beginning of *every* tokenized stream that identifies > it as such so that the collection manager can check individual streams > to determine exactly what they are. This will lessen the possibility > for data corruption, though not eliminate it completely. This is an > expensive operation and would also require changing the tokenized format. > > The other option is to task a collection as either 'binary' or 'xml'. I > am not opposed to saying that a collection can be a 'binary collection' > or an 'xml collection', but not both. My vote would be +1 for this > option. It wouldn't require changes to the tokenized format, and is a > solution that I think everyone can live with. > > > By the way, I do currently use base64 for embedding binary in my > > XIndice database, but it's not a good solution. > > FWIW, I agree with this. > > -- > Tom Bradford - http://www.tbradford.org > Architect - XQRL (XQuery Engine) - http://www.xqrl.com > Apache Xindice (XML Database) - http://xml.apache.org/xindice > Labrador (Web Services Hub) - http://www.notdotnet.org/labrador > >
