On Thu, 18 Jul 2002, Kimbro Staken wrote: > > On Thursday, July 18, 2002, at 12:50 PM, Fernando Padilla wrote: > >> > > > > So what are you thinking? I'm just going to plan to continue going over > > the code as I'm doing, but I'll assume that I can do an aggressive scrub > > down. > > What you're doing is very, very helpful, I'd just focus on the other > packages and ignore server. Also if you're serious about this we should > probably look into getting you commit if you want it.
I would love commiter status. About stopping work on server package, I feel like wittling away at the server code, to make it lean and mean. Then when it's time to surgically remove it, it might be alot easier. > For replacing server, we've thrown a couple things on the table. Using > Avalon is one, and just running under a servlet engine is another. The > servlet engine idea appeals to me the most, simply because it would have a > lot of flexibility and would be relatively simple. It would also probably > be less efficient, but I suspect that really won't matter as most of the > runtime cost is going to/should be in the core database anyway. We could > also take a similar route to Cocoon, where we use the support pieces of > Avalon, but run under a servlet engine. I don't know, I still haven't > taken the time to study Avalon in depth. Well, something to keep in mind is that the arcitecture has to maintain a single entity to maintain locks and integrity. A single servlet would do, but then the only way to access it is to send ServletRequests to it... One slightly different architecture that I might as well propose is to make a local Xindice Class/Interface which would be initialized by a Filter, and would make the Xindice Object available in the Session or in the Request Attributes inside the webapp. Then we could write servlets to deal with the API exposed to the world outside the server. It's an embedded Xindice, but exposed by a specific webapp. shrug, I might not have explained this the best. If anyone asks, I can give a better explanation tommorrow. > There's also some interesting possibilities architecturally from the > servlet engine scenario. For instance, if you're building a servlet > application you could run your application and the database in the same VM, > while still enabling concurrent access via the command line tools and > other tools like Attrezzo per Xindice. So you'd get the benefit of using > an embedded database, without the need to shut down your application to > use other tools. For larger applications, or non-servlet applications, you > would run a standalone servlet engine that just hosts a Xindice instance. > Really though, my main goal is to just move most of the issues in this > area outside of this project. We have a ton of work to do on the database > engine itself, the rest is really secondary. This is why I'm trying to cut > away as much code as possible. We may compromise the flexibility of the > software in the short term, but if we don't improve the core database this > project will become irrelevant very quickly. Alright.
