You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Fernando Padilla <fe...@interdimensions.com> on 2002/07/18 18:27:25 UTC
[PATCH] Kernel, Configuration janitorial
Hello.
So I'm going through the code to really learn what is really going on, so
I can add features. As I am going I'll be doing janitorial work.
Cleaning out unused/useless code. Looking for conceptual bugs.
Refactoring and Streamlining.
So just looking at Kernel and Configuration, I've found a lot of little
modifications to be made:
Configuration
- had a unused 'Modified' Map, and thus defunct 'setDirty' method.
- all of the 'setValue' methods had bad signatures
- and as an aside, these are all unused.
Kernel
- system.xml parsing code had minor cruft, unused variables, etc
- it exposed a Runnable interface, which is not good programming
- moved to internal class
- then saw that the runnable interface was just for task scheduling
- replaced with java.util.Timer and java.util.TimerTask implementation
of Task scheduling.
So except for the java.util.Timer, it was all interchangeable
modifications. Could someone get me feedback and/or check these in. I
would really appreciate it because I don't like being too much out of sync
with CVS.
Fernando
Re: [PATCH] Kernel, Configuration janitorial
Posted by Fernando Padilla <fe...@interdimensions.com>.
On Thu, 18 Jul 2002, Kimbro Staken wrote:
> These are in, thanks. Kernel's on the chopping block though.
I've noticed :)
Well then, how about the User and UserManager classes.. I know we
officially do not support users/security can I simply remove these out of
the code? They don't even exist in the system.xml
fernando
Re: [PATCH] Kernel, Configuration janitorial
Posted by Kimbro Staken <ks...@xmldatabases.org>.
These are in, thanks. Kernel's on the chopping block though.
On Thursday, July 18, 2002, at 09:27 AM, Fernando Padilla wrote:
>
> Hello.
>
> So I'm going through the code to really learn what is really going on, so
> I can add features. As I am going I'll be doing janitorial work.
>
> Cleaning out unused/useless code. Looking for conceptual bugs.
> Refactoring and Streamlining.
>
> So just looking at Kernel and Configuration, I've found a lot of little
> modifications to be made:
>
> Configuration
> - had a unused 'Modified' Map, and thus defunct 'setDirty' method.
> - all of the 'setValue' methods had bad signatures
> - and as an aside, these are all unused.
>
> Kernel
> - system.xml parsing code had minor cruft, unused variables, etc
> - it exposed a Runnable interface, which is not good programming
> - moved to internal class
> - then saw that the runnable interface was just for task scheduling
> - replaced with java.util.Timer and java.util.TimerTask implementation
> of Task scheduling.
>
>
> So except for the java.util.Timer, it was all interchangeable
> modifications. Could someone get me feedback and/or check these in. I
> would really appreciate it because I don't like being too much out of sync
> with CVS.
>
> Fernando
>
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
Re: [PATCH] Kernel, Configuration janitorial
Posted by Kimbro Staken <ks...@xmldatabases.org>.
On Friday, July 19, 2002, at 08:10 AM, Fernando Padilla wrote:
> On Thu, 18 Jul 2002, Kimbro Staken wrote:
>
> Alright. Kimbro. You're the man with the plan. I vote to just do it!
> Becuase I just realized the killer reason. I work for a consulting
> company, we build projects, but we do not host them. You can find a
> hosting provider that will host WebApplications. But it'll be hard one
> that will host an arbitrary server ( unless it's a big client .. ).
Yet another point in favor.
>
> So just do it, and/or please let me know what's the new top level class
Hopefully I'll be able to make the changes this weekend.
> for me to start to look at, since you're saying to definitly stop working
> on the server package...
>
Definitely org.apache.xindice.core.Database.
> exciting times
>
> fernando
>
>
>
>
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
Re: [PATCH] Kernel, Configuration janitorial
Posted by Fernando Padilla <fe...@interdimensions.com>.
On Thu, 18 Jul 2002, Kimbro Staken wrote:
>
> On Thursday, July 18, 2002, at 11:47 PM, Fernando Padilla wrote:
> >> .
> >
> > 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.
> >
> Don't waste your time with it. I already know how to get rid of it, it
> would take about ten minutes.
Alright. Kimbro. You're the man with the plan. I vote to just do it!
Becuase I just realized the killer reason. I work for a consulting
company, we build projects, but we do not host them. You can find a
hosting provider that will host WebApplications. But it'll be hard one
that will host an arbitrary server ( unless it's a big client .. ).
So just do it, and/or please let me know what's the new top level class
for me to start to look at, since you're saying to definitly stop working
on the server package...
exciting times
fernando
Re: [PATCH] Kernel, Configuration janitorial
Posted by Kimbro Staken <ks...@xmldatabases.org>.
On Thursday, July 18, 2002, at 11:47 PM, Fernando Padilla wrote:
>> .
>
> 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.
>
Don't waste your time with it. I already know how to get rid of it, it
would take about ten minutes.
>>
>
> 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.
Yeah this is basically what we'll be doing.
>
> shrug, I might not have explained this the best. If anyone asks, I can
> give a better explanation tommorrow.
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
Re: [PATCH] Kernel, Configuration janitorial
Posted by Fernando Padilla <fe...@interdimensions.com>.
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.
Re: [PATCH] Kernel, Configuration janitorial
Posted by Kimbro Staken <ks...@xmldatabases.org>.
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.
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.
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.
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
Re: [PATCH] Kernel, Configuration janitorial
Posted by Fernando Padilla <fe...@interdimensions.com>.
On Thu, 18 Jul 2002, Kimbro Staken wrote:
>
> On Thursday, July 18, 2002, at 09:27 AM, Fernando Padilla wrote:
>
> I wouldn't spend a lot of time on the code in org.apache.xindice.server
> (including Kernel). Other then org.apache.xindice.server.rpc, I'm hoping
> we can cut almost everything in there. I already have the system running
> under a simple HTTP server borrowed from the XML-RPC library. It literally
> took me five minutes to get it to work. So hopefully once we decide on the
> final direction for server framework it won't be too tough to convert over.
> Otherwise if you take a refactoring eye to that code, you're going to
> find a ton of stuff that isn't even used. It all came over from the
> Juggernaut code, and it's constantly annoyed me that there is so much
> unused code in there.
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.
> > So except for the java.util.Timer, it was all interchangeable
> > modifications. Could someone get me feedback and/or check these in. I
> > would really appreciate it because I don't like being too much out of sync
> > with CVS.
>
> OK, I'll look at them.
thank you very much.
fernando
Re: [PATCH] Kernel, Configuration janitorial
Posted by Kimbro Staken <ks...@xmldatabases.org>.
On Thursday, July 18, 2002, at 09:27 AM, Fernando Padilla wrote:
>
> Hello.
>
> So I'm going through the code to really learn what is really going on, so
> I can add features. As I am going I'll be doing janitorial work.
>
> Cleaning out unused/useless code. Looking for conceptual bugs.
> Refactoring and Streamlining.
>
> So just looking at Kernel and Configuration, I've found a lot of little
> modifications to be made:
I wouldn't spend a lot of time on the code in org.apache.xindice.server
(including Kernel). Other then org.apache.xindice.server.rpc, I'm hoping
we can cut almost everything in there. I already have the system running
under a simple HTTP server borrowed from the XML-RPC library. It literally
took me five minutes to get it to work. So hopefully once we decide on the
final direction for server framework it won't be too tough to convert over.
Otherwise if you take a refactoring eye to that code, you're going to
find a ton of stuff that isn't even used. It all came over from the
Juggernaut code, and it's constantly annoyed me that there is so much
unused code in there.
>
> Configuration
> - had a unused 'Modified' Map, and thus defunct 'setDirty' method.
> - all of the 'setValue' methods had bad signatures
> - and as an aside, these are all unused.
>
> Kernel
> - system.xml parsing code had minor cruft, unused variables, etc
> - it exposed a Runnable interface, which is not good programming
> - moved to internal class
> - then saw that the runnable interface was just for task scheduling
> - replaced with java.util.Timer and java.util.TimerTask implementation
> of Task scheduling.
>
>
> So except for the java.util.Timer, it was all interchangeable
> modifications. Could someone get me feedback and/or check these in. I
> would really appreciate it because I don't like being too much out of sync
> with CVS.
OK, I'll look at them.
>
> Fernando
>
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