On Saturday, February 16, 2002, at 09:24 PM, Tom Bradford wrote:
That's fine... just don't think there should ever be an actual release based on a Sleepycat hybrid.
Of course. We can't do that if for no other reason then licensing.
It will be a long time before we can depend on 1.4 though. I doubt it will happen within even the 2.0 release cycle.
Not to mention the fact that Mac OS X doesn't have a 1.4 implementation yet.
Yeah. :-(
What are we tracking today?
FS, Mem, Hash, and BTree. It may be useful to implement a mapping Filer in addition to a tightly controlled relational backend.
Sorry, that isn't what I meant, I was asking about meta-data. What meta-data are we tracking about documents?
Because it's code that's already there, it wouldn't take very much to maintain, it could establish the foundation for Triggers, and there are some who are actually using it.
Well, my point was more about the concept. I'd prefer to tell people that to extend the server just write a servlet or some such thing rather then having to explain the concept of XMLObjects. Servlet is probably the wrong idea, but I want to leverage existing concepts and documentation rather then pretending it is something different.
In general I agree, but given a choice between pulling in an existing project and trying to bootstrap a new one I'd probably choose the former.
I'm thinking more of the ColdFusion/PHP interface that was being developed in the past.
If we're going to make it part of the project though, it should probably be java.
Axis, XML-RPC, and Labrador all have certain overlap. I'd say their goals are all different. At the moment, the Axis project seems to have little to no interest in XML-RPC, and the XML-RPC implementation doesn't aspire to do much more. Aside from that, both projects target the client and server, whereas Labrador is laser focused on the Server.
How hard do you think it would be to add XML-RPC to Axis vs. adding SOAP and associated baggage to Labrador? Regardless, why do we even need it? I can easily expose the same class through Axis and Apache XML-RPC without using Labrador. We really don't need a generic web services framework to expose any class, we just need to be able to expose our API classes easily.
I see this as trading one unnecessary complexity, CORBA for another less mature one, Labrador.
2. It is very immature and missing large amounts of functionality.
And Xindice isn't? :)
That isn't the point, Questions of maturity of Xindice are to be asked by people looking at using Xindice. We're looking at using Labrador and questions of maturity are of critical importance.
4. There is no community supporting it, this makes it very risky.
Not as though I've been actively evangelizing the project. I'm trying to build out the project to the point where its actually useful before doing a big push.
You want us to gamble that this will emerge? I don't want to take that bet right now. Doesn't mean it won't pay off, just that the odds are against it right now. Consider it incentive to prove me wrong. :-)
To be honest, I'd be more likely to first walk away from Xindice than Labrador because of time constraints as Labrador is a smaller project, and much easier to manage even when it becomes more mature. I'll
And that is fine and not at all surprising. My goal right now, and I consider it more important then anything else, is to bring other developers in so that either one of us can walk away and not have it kill the project. The project isn't healthy if that isn't the case.
Bringing in Labrador just brings that much more dependency on you and I really do not want that. It isn't healthy for the project overall.
continue to work on both as I see Xindice being the ultimate test case for Labrador, and my employer has some interest in seeing Xindice become more popular.
Personally, I don't want Xindice to be a test case for Labrador. In my opinion, Labrador is a good idea, but needs to be more mature and proven before we commit to using it.
Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/
