Well my point wasn't that we should avoid it, but that we should consider using it as a starting point. It would allow us to focus initially on the higher level transactional concepts and figure out how we make the overall system transactional before diving into the really difficult stuff. I don'
t see a problem with telling people for the short term that if you need transactions you have to go download some sourceforge project to get them.
I'm not suggesting it as a long term solution, just as a bootstrap.
That's fine... just don't think there should ever be an actual release based on a Sleepycat hybrid.
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.
Is Ari still working on it?
Don't know. I'll take a look.
11. Linking 1. To keep and mature or to eliminate?
I'm for eliminating it.
I'm still not sure about this. It's not a priority either way, but I'm not prepared to dismiss the idea yet.
12. Expanded in database meta-data 1. Need to see exactly what we do and do not have here.
It's something I've wanted. It's hard to implement consistently if we expand out to several backends, but it's workable.
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.
Not so sure. I would still lean toward having them. If we were to incorporate Labrador, XMLObjects would be a free. We'd only have to write enough code to load and instantiate classes, but not much else.
If you're embedded in Tomcat why do you need a separate concept? Why not just build on something that already exists?
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.
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.
I have several concerns with Labrador and I'm not at all convinced it is what we need or the way we should go. Here's the issues I have with labrador, note my issues are mostly non-technical and have nothing to do with my opinion of Labrador on a technical level. My comments only apply to its use within the scope of the Xindice project.
1. It overlaps in goal with Axis, http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-
axis/java/docs/requirements.html Axis may not support XML-RPC today, but then Labrador doesn't support SOAP either. SOAP is a lot harder then XML-RPC.
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.
2. It is very immature and missing large amounts of functionality.
And Xindice isn't? :)
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.
5. The framework is relatively complex. While it is simple to plug in basic services the immaturity of the framework it self and the lack of community will necessitate our needing to fix issues in the core code. This brings a lot of baggage and risk.
Basically, if we use Labrador and you decide/are forced to stop working on it for whatever reason this community will have no choice but to pick up maintenance. This is not a safe thing to depend on. I'd prefer to simply depend on Axis and Apache XML-RPC directly and defer all development on protocol support to those communities. If Labrador develops momentum and a community then we can look at refactoring to leverage it. Until then I do not think using it is the right decision for this project.
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 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.
What functionality are we getting from Avalon?
If we were going to map our current use of Juggernaut to Avalon, we'd be using Components, Lifecycle, and Logging facilities, but not much more.
Yeah, i didn't mean we should focus on it completely, just that we don't really focus on it very much right now. I think embedding will be a very common use so I want to make sure it's clear how to do it and that it becomes a focused goal while developing.
I agree.
-- Tom Bradford - http://www.tbradford.org Architect - XQRL (XQuery Engine) - http://www.xqrl.com Apache Xindice (Native XML Database) - http://xml.apache.org Project Labrador (Web Services Framework) - http://notdotnet.org
