[regarding the XNode API...]
Dave Viner wrote:
Hi,
I would like to propose a course of action regarding metadata storage in
Xindice. First, I propose to commit the changes I posted at
http://marc.theaimsgroup.com/?l=xindice-dev&m=103946437104874&w=2 Second, I
propose to commit Murray's XNode api to the scratchpad. (Murray, if you
can send me a set of .java files that implement the XNode api, I will commit
them to the scratchpad, and make sure that they compile.)
Will do, under separate cover.
This will allow developers to see if the concept of metadata is useful
in
Xindice. It seems clear from several threads that metadata is a
controversial subject, but I believe that this functionality will be
extremely useful for those who need it, and will be unobtrusive to those who
don't. If people still feel strongly that any metadata solution should not
be in the core, then I will call for a vote seperately on this topic. If no
one objects strongly, I will commit my changes and Murry's code.
I discussed some of the issues with Vladimir, and thought I'd
note several things:
1. The API's package is org.apache.xnode.*. Vladimir suggested
I change this to org.apache.xindice.xnode.*, but I've not
yet done this, partly because I'm not sure it's a correct
course of action -- XNode is an API that doesn't "know" about
Xindice, ie., Xindice is not even mentioned in the code --
it's independent. (I also hesitate because I've been using
the current API as-is for over a year and have a fairly
extensive personal store of data, so unless the change is
truly necessary, I'd rather not have to transform all that
data.)
2. The XNode API is currently only an API -- there is no
implementation included in what I'm sending Dave. I've got
a working implementation in my Ceryle project, but it'd
take a bit of work to make it independent. I've got i18n
and error messaging features that rely on Ceryle that can
be removed, and I'm willing to do so later this Spring if
people want to add that code to the Xindice code base. One
of the reasons I've not done this previously is that I was
trying *not* to assume to inflate the Xindice code base;
the API itself is quite tiny.
3. You'll perhaps note a similarity to SOAP. This is SOAP-lite,
or SSOAP (simple simple object access protocol, what SOAP
pretended to be when MS shoved it under the W3C's door, not
what it turned out to be).
Currently it doesn't support metadata at the Collection level,
but I don't think this would be too difficult an addition if
people like the basic idea; almost a cut and paste.
4. The API documentation is currently at
http://kmi.open.ac.uk/projects/ceryle/doc/api/
paying attention to org.apache.xnode.* and org.ceryle.xnode.*
There's a subtree that's currently unfinished for zipping a
Collection up as an archive -- I've got the ZipWriter working
just fine, but haven't implemented the prototype ZipReader
yet, so I've not finished that part of the API. I'm not
certain I want to actually add this to the API at this point,
though it is quite handy. I have a GUI dialog that allows me
to select one or more Collections, which then get zipped up
to a file. Pretty simple, really.
Thanks all for your consideration on this, and have a relaxing
holiday. I'm in Portugal until January 10th, out of touch until
then.
Murray
......................................................................
Murray Altheim <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK
If you're the first person in a new territory,
you're likely to get shot at.
-- ma
