I agree. I think you are right, the core pieces need to be defined as Interfaces. Everyone should code to those.
Right now everyone sees the XML:DB as the interface to Xindice, as I do also. In reality, there is a Xindice interface defined through the org.apache.xindice.core.* classes. The CORBA and XML-RPC interfaces provide an API to use these classes. That API is the one defined by XML:DB. So it seems the first step should be to define interfaces to the "core" of Xindice. And then implement the XML:DB API on top of that, without using CORBA or XML-RPC. When that is done, we should be able to talk to Xindice either remotely or embedded with the same API. The question to be asked later is whether or not XML:DB is the best Interface to use. For right now, I think it is, but it is holding us back. Some of the answers to questions are "because the XML:DB API doesn't support that". Since Kimbro is part of the XML:DB project, he can speak to what it will take to get the API modified. We have two choices, one stick with XML:DB or invent/use a new one. For right now, I say we stick with XML:DB. One because it is in place and people have coded to it. Two, because the XML-RPC initiative is in progress and they might as well finish. And three don't change too many things at once. I would just as soon see one API available as three different implementations than everyone running off in three seperate directions. Also, the test classes should work for all three implementations. Thoughts? Kimbro am I correct in my description? Mark Kimbro Staken wrote: > On Thursday, June 13, 2002, at 01:59 PM, Matt Liotta wrote: > > > Isn't XML:DB just a set of interfaces? > > Yes. > > > Doesn't Xindice provide more > > functionality than what is in XML:DB? > > Yes. > > > Thus, it would seem that Xindice > > needs to provide its own API that mostly matches XML:DB, but also > > supports Xindicisms. > > Yes, the XML-RPC API provides this for network access and the internal > classes provide it to anyone who wants to embed the database. Really > though, the internal structure needs to be refactored to make it clearer > what the APIs are and to also make them less susceptible to change. It's > kind of risky to build against the internal classes directly, but right > now there's no alternative. > > > Then you could have many different implementations > > of the Xindice API. > > I think there should be two APIs that are Xindice specific. > 1. A network API (current CORBA, future XML-RPC) > 2. An internal API (org.apache.xindice.core.Database, Collection and > friends - needs refactoring) > > Whether those match or not, in my opinion doesn't matter because the > medium is so different. > > So then the question becomes what is the API people use to build > applications? To this point we've always used the XML:DB API for this > purpose, at least for Java developers. If your question is whether or not > we should continue to do that? Then that is something I've been wondering > too. What's actually important though, is making sure the appropriate > information is available outside the database engine. The two APIs above > cover that, so to me those are the most important ones to be concerned > with. From there people can build whatever APIs they want, or just use the > XML:DB API. > > I understand completely if you're confused. Again this is why I really > wish we had originally packaged this as an embedded database. In that > scenario it would be much clearer what is the database and what is really > an add on component that provides a particular service. Really everything > like the CORBA API, XML-RPC API, XML:DB API, command line tools and all > that are just add ons. People should be building whatever add ons they > want and shouldn't be concerned with whether or not the core project > codifies them as the "official" way. The current Xindice server package > should really have been viewed as just one possible packaging of the > Xindice database engine. I'm curious does anyone else agree with this? > > > -Matt > > > >> -----Original Message----- > >> From: Kimbro Staken [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, June 13, 2002 1:53 PM > >> To: [EMAIL PROTECTED] > >> Subject: Re: Xindice as a servlet? > >> > >> > >> On Thursday, June 13, 2002, at 01:30 PM, Matt Liotta wrote: > >> > >>> If the CORBA and/or XML-RPC implementations where just layers on top > > of > >>> the local implementation this wouldn't be an issue. > >> > >> Why would you want to add another layer inside the server? Unless I'm > >> misunderstanding, what you're suggesting is. > >> > >> XML:DB API -> network -> CORBA -> local XML:DB API -> Core classes. > >> > >> Or alternatitvely > >> > >> XML-DB API -> network -> XML-RPC -> local XML:DB API -> Core classes. > >> > >> As should be apparent from this there's no value in adding the local > >> XML:DB API into the stack. Both the CORBA and XML-RPC services are > > already > >> just layers implemented against the same set of internal classes. > >> > >>> Simply add a > >>> configuration directive to specify whether you want a CORBA or > > XML-RPC > >>> implementation to be made available. > >>> > >>> To answer you other question, yes, I would be willing to help code > > it. > >>> > >> > >> What would be valuable is for someone to write the local XML:DB API > >> implementation. It's really not that hard. Just about anyone who is > >> embedding the server would probably like to see that. It would make it > >> quite simple to move from an embedded database to a full network > > database > >> simply by using the alternate XML:DB implementations. > >> > >>> -Matt > >>> > >> 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 > > > > > 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 -- Mark J Stang Architect Cybershop Systems
begin:vcard n:Stang;Mark x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Mark Stang end:vcard
