It occurred to me that some folks would prefer zip compression, so the zip versions are attached to this email.
Gary
On Thu, 6 Mar 2003, at 13:20 [-0700], Gary Shea ([EMAIL PROTECTED]) wrote:
> Attached find patch and tar files (bz2 encoded) to enable binary
> resources in Xindice. Tests included. The patches currrently only
> handle embedded XML:DB. Adding the native XML-RPC messages and remote
> XML:DB client should be no problem, but I wanted to get the internals
> accepted first.
>
> A couple notes about the attached patches. First,they include the
> patches I submitted a week or two ago for XML-RPC parser indpeendence,
> as those haven't found their way into the codebase yet. Sorry for the
> extra clutter. Also, the patches include tons of log.debug() stuff.
> I'll be happy to remove all that when the code settles down.
>
> The approach I've taken is to start out by creating a flexible and
> extensible inline metadata service, activated on a per-collection basis.
> (By inline metadata, I mean that the metadata is a header at the
> beginning of the BTree data.) That gives me an efficient way of
> determining what type of resource a particular BTree record holds. All
> the code for the inline metadata service is in
> org.apache.xindice.core.inlinemeta.
>
> Because the Xindice BTree doesn't care much about what you put into it
> (bytes, bytes, bytes), binary records are ordinary BTree records.
>
> Most of the details for managing binary resources is found in
> Collection. The low-level getDocument() and putDocument() methods have
> been joined by getEntry() (record type agnostic, needed for XML:DB),
> getBinary(), and putBinary().
>
> All unit tests succeed; test-integration-embed works except for the
> XUpdate test that's been failing all along; I actually haven't tried
> test-integration-xmlrpc, whoops!
>
> To run a binary-specific test, try: bin/ant test-embed-binary
>
> One final note, these patches also fix a bug associated with
> XMLSerializable. Most of the implementations of streamFromXML(Document)
> added themselves to the parent document, but putObject() in Collection
> also added the Element returned by streamFromXML(Document) to the document,
> causing it to end up in there twice. Took me a while to figure out that
> one!. To me it made more sense that a method should act as locally as
> possible, reducing side-effects, so now no
> XMLSerializable.streamFromXML() implementation adds itself to its parent
> Document.
>
> Have fun!
>
> Gary<<attachment: diffs.txt.zip>>
<<attachment: files.zip>>
