Wow, welcome back Kimbro! On the note of moving forward, I like the idea of Kimbro concentrating on a 2.0 architecture, using the lessons learned with the current codebase (because he knows more than anyone the lessons learned). I'm sure some of us committers without core development knowledge (or interest) can keep the current setup running in a stable fashion.
Kimbro, I do ask that you publish (on the xindice website) your goals for the architecture, and possibly any other information you have to add. If you need any guidance on jumping into the new forrest documentation structure, let me know and I can give you a jump start. I think that showing the world the future of xindice will be helpful in many ways. -Kevin Ross -----Original Message----- From: Kimbro Staken [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 4:10 PM Ahh, the good ole struggling to get people to actually write code problem. This is something that's been a problem for this project going back to the dbXML days. I'm just happy that there are still people who actually care enough to participate in this thread. That to me is a very good sign, now we just need to figure out how to get to the next step. Before we can do that though we need to recognize a few things. 1. XML databases are pretty obscure and there aren't a lot of people who know anything about them. 2. Writing a database is a damn hard thing to do. 3. None of us knows anything about writing databases. 4. None of us knows what a native XML database really needs to be. Maybe stating the obvious, but it helps for me to keep this in mind. It means we have no right answers, and if we get caught searching for the one right answer we'll never move forward (i.e. metadata). This project is a big experiment, because it started as a business I didn't always see it that way, but now I know better. There's no maturity here, and we shouldn't move forward with any illusion that there is any. We have no idea how to build an XML database, and if we can accept that what we have is just wrong maybe we can finally move forward with new development. So for moving forward I'm suggesting we start 2.0 by assuming everything we've ever done is wrong and we need to start from scratch. :-) Hopefully, we'll get a few things right for 2.0 so that we don't have to do it all again for 3.0, but our territory is uncharted enough that it may still happen. BTW, I don't believe anyone knows how to do XML databases, but I do still believe there is real value there. Anyway, I agree we should be discussing this in public, so I'm just going to address the library issue here, since I'm the person who started the whole mess. To start, let me be clear, I also see Xindice as being much more like MySQL then like Berkeley DB. So this means my personal opinion is that we should always ship a server version of the software. However, just like MySQL which can be built as a library for embedded use, Xindice should also be fully usable in that context as well. My intention in attempting to focus the database core development around a library was for a number of reasons. 1. This is Java, not C. There are numerous preexisting Java mechanisms that are available to run server processes and it always bugged me that we had several thousand lines of code dedicated to something that did the exact same thing as a servlet engine. 2. The old server didn't really treat the database any different then a library anyway. Running the database in a servlet engine (or any other server framework) is simply no different. 3. The skill level required to work on the server pieces is very different then that required to work on the core database engine. Basically my intention was to create a clear division between the two pieces in the hope that this would enable people to participate in one or the other area without feeling the need to understand all the detail from the other. My intention however, was definitely not to split the community, simply to bring a clearer modularity and slightly different focus for the core engine developers (i.e. to keep in mind that they weren't always going to be deployed as a server) and for the server developers (i.e. that they were going to just need to work on a solid packaging of the library). 4. I wanted to make it much clearer and easier for people to build alternative server mechanisms that differ from those of the core project (i.e. if someone wanted to build a new CORBA based server or whatever). 5. To make the effort needed to build the server pieces much smaller. 6. To make Xindice usable in a wider variety of applications. 7. To make something like building a simple servlet that uses Xindice much easier. (i.e. no server setup required, no separate start scripts to start the database) 8. To improve performance in single system installations by enabling the database to be run in the same process as the application. (assuming a Java app) I'll certainly take the blame if the server bit got lost. I don't remember how clear we were on that, I definitely talked a lot about focusing on being a library (maybe too much) but I fear that I wasn't clear enough in what my real intention was behind those statements. I definitely never wanted to kill the server completely. I was trying to step back and look at things from a different perspective and in doing so realized a few possibilities that are different about building a database in Java vs. a more traditional C project. So my opinion is that the Xindice database engine should be a library, but the Xindice project should still offer a fully functional server version of the software. BTW, my personal interest going forward is to work on the core database engine, in particular 2.0. I don't want to have to worry about the server pieces, release management or steering the project, fortunately now it seems we have a real team of committers and if we work together we can finally turn this thing into something truly useful. Kimbro Staken Java and XML Software, Consulting and Writing http://www.xmldatabases.org/ Apache Xindice native XML database http://xml.apache.org/xindice XML:DB Initiative http://www.xmldb.org
