Alright Tom. So I guess it wasn't as easy as we were led to believe by your last email.
The capability is there, hidden neatly away in the Filer interface, but the problem is exposing it, which I never suggested a solution for until now.
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..
The client and the backend can assume this based on the API calls that are made. getDocument implies a document resource, while (in the future) getBinary implies a binary resource. The server will kindly throw exceptions if you make a call that the collection won't be tasked for.
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...
This suggestion wouldn't actually break anything as it would be additive. Regarding UTF-8, not sure... My guess is 2.0.
-- 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
