On Fri, 28 Jun 2002, Tom Bradford wrote: > On Friday, June 28, 2002, at 10:06 AM, Fernando Padilla wrote:
> 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. - wait, so the client code will return an XindiceResource which will implement both BinaryResource and XMLResource??????? I wouldn't be too happy about that. - as an aside, I could see an XMLResource implementing the get/setContent methods to serialize/parse the binary content into SAX/DOM then call the get/setContentAsSAX ( actually this should be an easy patch ) Essentially though an interim solution where the Resource Type is stored at the Collection level is great!, I still think we should start moving things over so that this information is maintained at the Resource level... This might break things ( like you said, it might affect the token stream or something ), but it will make things better in the long run. The only thing I see is that it will probably break more than we expect because most of the code probably has an assumption of only XMLResources ( like possibly the XPath/Indexer ).... What do you think? fernando
