Murray Altheim wrote:
A good reason to not include a metadata implementation in the main code base is that there are quite a lot of approaches to metadata storage, and to the types and complexities of metadata itself, and these vary depending on application. I developed the XNode API as an attempt at creating a *very* lightweight API. If there are three approaches, ordered in terms of complexity, we'd have
1. XNode API 2. (Dave Viner's) Metadata implementation 3. JMI-in-Xindice
I think that these are all way of *accessing* metadata, where I agree that we have a pluggability spot. My concern, instead, is about low end metadata storage which is totally missing and badly needed. Once we have a flexible storage (and IMHO Dave's solution is KISS and effective on that point, but it might evolve into something more powerful), we might be able to talk about different (and yes, pluggable) ways of accessing the metadata.
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.
There is a dark side in everything. In this case, I think that there is a balance between flexibility and performance, and a risk of exchanging flexibility and Flexibility Syndrome. As I said in a previous post, I can hardly imagine a common "internal" API that allows for pluggable stuff deeply inside Xindice core. We might hit a very hard wall when we want to push performance while being stuck to a particular API (as it is now, where all the pluggable parts have to go trough DOMs floating all over the place which is, to say the least, suboptimal).
Finding that balance is hard: I completely agree on modular architectures and the like, but there is a point where you have to stop. The risk is coming out whith the dreaded "Object doSomething(Object withThis)".
In your design, Dave, couldn't the entire metadata tree be under its own package rather than having MetaSystemCollection be in package org.apache.xindice.core? (I do understand you've probably designed it as part of core.)
Not until we agree on how to manage an internal API. The only way I can see that is working on a set of Listener interfaces, that react to changes to the database (maybe the DBObserver can be a good place to start). But it won't be an easy task, even if definitely worth the effort, since it would allow for triggers, monitors, and any other dynamic behaviour on database changes.
But we are already talking about Xindice 2.0, I guess. And we need (or at least I do, and all the people I talked to about Xindice do) some metadata support now. So what is the best solution?
Ciao,
-- Gianugo Rabellino
