Hi,
Sorry for my delayed response, and thanks to everyone for responding to
my suggestion. There have been several different responses to my initial
email, but I'll try to address each one. If I've missed anything or glossed
over anything, please let me know. I'm still digesting today's discussion
between Murray and Gianugo, so that's not yet taken into account here.
Issues:
1. Make metadata an "addon".
2. Put it in the scratchpad and use package other than org.apache.xindice.core.
3. Implement or use XNode.
4. Use config file for configuring metadata usage.
Issue 1. Make Metadata an "addon".
I think the idea of addons is a good one. I think Xindice would
benefit greatly from a more modular architecture. (I like to imagine Xindice
working like the Apache webserver with its dynamic shared object model.)
However, Xindice does not currently have any such facility of which I am aware.
If there is one currently, please let me know.
It seems to me that, like other native XML databases, Xindice is often
used in the "Content Management" style of system. For applications like that,
metadata storage (in some format) is extremely useful. In fact, I am using
Xindice in that style currently, and this code is born of the need to associate
metadata with documents and collections. Since I am unaware of any addon
capability, I (with much help) hacked into the core the metadata functionality.
I suspect that other users of Xindice would benefit from this type of feature
but are unwilling (or don't have the resources) to implement such
functionality. So, I would argue, this feature should be added sooner rather
than later. And since there hasn't been much in the way of discussion about an
more modular architecture, I would argue that we should add metadata support to
the core.
If we as the development team of Xindice come up with a design or
suggestion for how to implement a more "pluggable" architecture, I'd be all for
revamping my MetaData stuff to work in that model. But, given our current pace
of development, I'd rather include metadata functionality now, and refactor it
later when the core becomes more modular.
(As a side note, I completely agree that the Xindice core should stay
"lean" and avoid bloat. However, I personally don't think that functionality
that would be useful for a whole class of applications (like CMS) should be
considered bloat. It would probably be better if such features could be
added on in a more modular fashion, but I don't think Xindice should refuse new
(and beneficial) features just because we haven't made the core system
pluggable. But that's my personal feeling on bloat. I'm sure everyone has
their own ideas about what is and what is not bloat.)
Issue 2. Put it in the scratchpad and use package other than
org.apache.xindice.core.
I'd be happy to put my code into the scratchpad. I still don't quite
understand the purpose of the scratchpad or how things move from the scratchpad
and into the main tree, but I'm sure someone else can enlighten me there.
As for the package location, I'm pretty sure that I could rework
MetaSystemCollection to live in some non-core package, but I think that would
require the modular addon style of core code which we don't yet have.
Issue 3. Implement or use XNode.
Murray summarized the discussion well in his earlier email from this
thread (available at http://marc.theaimsgroup.com/?t=102873960400001&r=1&w=2).
He said, "there are essentially two ways of attaching metadata to a db record:
one, in the record itself (XNode), two, in a separate db record." XNode adds
metadata at a Node level, my implementation (which sadly lacks any cool name)
adds it at a document or collection level. XNode alters the document that is
stored (somewhat) and the API to retrieve it, whereas mine does not.
Essentially XNode and my implementation serve two distinct purposes. So, I
don't think my implemenation could also implement the XNode API. They simply
serve different design goals.
I suspect that one could develop yet another implementation of metadata
storage that we be distinct from either of these two, and yet serve some useful
purpose. I think metadata is a rather complicated problem and that there are
many solutions. I have presented one solution for integration. I don't think
my implementation would preclude the implementation of an XNode storage
capacity. (And if it has, please let me know so I can change my code!)
For the manner in which I use Xindice, I don't need XNode. But I can
envision circumstances, and Murray has clearly encountered those circumstances,
where XNode would be useful. I would be in favor of commiting any well design
and well coded patches that implement XNode too.
Issue 4. Use config file for configuring metadata usage.
In fact, I made an attempt to use the config file in this
implementation. If this code is added to the main tree, by default nothing
actually changes for a Xindice user. The user must turn on metadata storage by
editing the system.xml file and changing the value of the "use-metadata"
attribute of the root element. If this configuration is not changed, all
method calls relating to metadata simply return immediately.
However, I believe that you were thinking of an even more powerful type
of configuration, such as configuring which implementation of metadata to use
(my style, or XNode, or this jmi style, or some other series of classes). I
think this type of configuration would be terrific. I would be totally willing
to work out a more flexible configuration than what I've done (which is just
toggle metadata storage on or off). Are there other implementations of
metadata that we can add currently? I haven't come across any code that
implements metadata storage in Xindice. So, I'd be happy to work out a more
flexible configuration style, but I just didn't have any other examples to work
with.
So here's what I propose:
1. Incorporate this implementation of metadata (unless there are others ready
for addition to the tree)
2. Define a more modular core architecture that would allow this code to be
refactored into a pluggable module
3. Implement that more modular design, and refactor this implementation into a
module.
Thanks
Dave Viner
-----Original Message-----
From: Kurt Ward [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 10, 2002 9:52 AM
To: [EMAIL PROTECTED]
Subject: Re: second impl of metadata storage
> If we make the Xindice addons truly modular, then any of the proposed
> metadata solutions as well as other non-essential features can be
> easily added to a Xindice application without enlarging the core code
> and complicating the lives of those who don't want or need metadata.
> I like the idea of a trim Xindice rather than including everything,
> and given this is a public process I'd hate to see it bloat out like
> some things.
How can we do this in a similar fashion to 1.0? The configuration file in
1.0 allowed us to add and remove components in a very nice way. Using the
config file wasn't really documented, and I'm sure there are some components
that most people don't even know about (HTTP GET handler for document
retreival, the XML-RPC server, and a DB Conduit for connecting to JDBC
datasources from Xindice, etc.).
Kurt
