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 Terry Rosenbaum <Te...@amicas.com> on 2003/06/05 09:25:39 UTC
MemValueIndexer
Attached are a couple of classes that you may find
useful. Not a major piece of work, but I'm donating these
to the cause if anyone is interested in checking them in as part
of Xindice.
Attachments:
1) MemValueIndexer.java
* Provides an in-memory implementation of Xindice Indexer
* based upon the Java TreeSet class. This implementation
* is not persistent. A MemValueIndexer is useful for indexing
* of temporary Collections (e.g. those based on MemFiler). It is also
* useful for temporary indexing of persistent Collections.
Note that this indexer stores values as Java objects. Comparisons
are performed using Java comparison. This indexer correctly handles
comparisons of signed values for numeric index types, etc. (unlike
existing ValueIndexer).
2) SizeableMemFiler.java
A Filer which is a wrapper around the Java HashMap.
Just like existing MemFiler except that the initial size
of the HashMap is set via System property named
"org.apache.xindice.core.filer.SizeableMemFiler.INITIAL_SIZE".
Using these 2 classes together, you can run Xindice
as an in-memory database (non-persistent).
RE: MemValueIndexer
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
Committed to the main trunk.
Vladimir -1
Kurt +1
Kevin +1
-----Original Message-----
From: Terry Rosenbaum [mailto:Terry@amicas.com]
Sent: Thursday, June 05, 2003 1:26 AM
To: xindice-dev@xml.apache.org
Subject: MemValueIndexer
Attached are a couple of classes that you may find
useful. Not a major piece of work, but I'm donating these
to the cause if anyone is interested in checking them in as part
of Xindice.
Attachments:
1) MemValueIndexer.java
* Provides an in-memory implementation of Xindice Indexer
* based upon the Java TreeSet class. This implementation
* is not persistent. A MemValueIndexer is useful for indexing
* of temporary Collections (e.g. those based on MemFiler). It is also
* useful for temporary indexing of persistent Collections.
Note that this indexer stores values as Java objects. Comparisons
are performed using Java comparison. This indexer correctly handles
comparisons of signed values for numeric index types, etc. (unlike
existing ValueIndexer).
2) SizeableMemFiler.java
A Filer which is a wrapper around the Java HashMap.
Just like existing MemFiler except that the initial size
of the HashMap is set via System property named
"org.apache.xindice.core.filer.SizeableMemFiler.INITIAL_SIZE".
Using these 2 classes together, you can run Xindice
as an in-memory database (non-persistent).
Re: MemValueIndexer
Posted by Terry Rosenbaum <Te...@amicas.com>.
Kevin Ross wrote:
>Your classes would seem to be very useful in the case where the db
>engine implemented some sort of profiling, and wanted to add an index on
>the fly, correct?
>
Yes. That would be a use for this type of index.
Though you could also do the same with a
regular persistent index.
I developed these classes to run Xindice completely
in-memory (well, completely in VM at least :). Our application uses
Xindice as a temporary
database exclusively because we have difficulty synchronizing content
the XML database with other parts of the app 100% at all times.
Using a temp DB makes it self-healing at each startup (at the expense
of startup speed). The XML DB is loaded from a RDBMS where the
data is persistent. Also, we cannot trust the robsutness of the
Xindice DB persistence (no transaction logging, roll-forward recovery,
etc.). I'm not
complaining that these features are not present, merely stating a
fact. Xindice is still useful as we use it.
-Terry
>Hi Terry,
>
>I'm not a db guru by any means...but...tell me if my idea is correct.
>Your classes would seem to be very useful in the case where the db
>engine implemented some sort of profiling, and wanted to add an index on
>the fly, correct? This would be somewhat analogous to the way the
>hotspot VM goes native with heavily traveled byte code?
>
>How do you specifically apply these classes in your applications?
>
>I'm +1 for adding these to the main trunk. If there are no objections,
>I'll do so.
>
>-Kevin Ross
>
>-----Original Message-----
>From: Terry Rosenbaum [mailto:Terry@amicas.com]
>Sent: Thursday, June 05, 2003 1:26 AM
>To: xindice-dev@xml.apache.org
>Subject: MemValueIndexer
>
>Attached are a couple of classes that you may find
>useful. Not a major piece of work, but I'm donating these
>to the cause if anyone is interested in checking them in as part
>of Xindice.
>
>Attachments:
>
>1) MemValueIndexer.java
>
> * Provides an in-memory implementation of Xindice Indexer
> * based upon the Java TreeSet class. This implementation
> * is not persistent. A MemValueIndexer is useful for indexing
> * of temporary Collections (e.g. those based on MemFiler). It is also
> * useful for temporary indexing of persistent Collections.
>
>Note that this indexer stores values as Java objects. Comparisons
>are performed using Java comparison. This indexer correctly handles
>comparisons of signed values for numeric index types, etc. (unlike
>existing ValueIndexer).
>
>2) SizeableMemFiler.java
>
>A Filer which is a wrapper around the Java HashMap.
>Just like existing MemFiler except that the initial size
>of the HashMap is set via System property named
>"org.apache.xindice.core.filer.SizeableMemFiler.INITIAL_SIZE".
>
>Using these 2 classes together, you can run Xindice
>as an in-memory database (non-persistent).
>
>
>
RE: [my philosophy] was RE: MemValueIndexer
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
I'll write up the reorg structure and send it out. We can agree on the
new structure, then we'll setup a reorg time, and I'll make it happen.
Soon to follow...
-----Original Message-----
From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
Sent: Thursday, June 05, 2003 11:20 AM
To: xindice-dev@xml.apache.org
Subject: RE: [my philosophy] was RE: MemValueIndexer
> I'm +1 for a supported 'addons'.
Finally one +1 for something I proposed :-)
> BUT, I want the build system integrated for users to be able to do
this
> flawlessly. I believe maven may be able to help make this happen.
We'll cross that bridge when we get there. Do not forget that users
work with a
release, not with the cvs build. And since the release typically
doesn't
contain the build.xml file, solving users' problems with the build.xml
file is
not the right thing to do.
> maven release add:webdav add:xyz
>
> Of course if webdav and xyz conflicted on something like the web.xml,
> I'm not sure how to handle this...maybe I'm dreaming.
In the meantime, a _very_ good documentation (cookbook like) should be
just
fine. IMO maven is not necessary.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
RE: [my philosophy] was RE: MemValueIndexer
Posted by "Vladimir R. Bossicard" <vl...@apache.org>.
> I'm +1 for a supported 'addons'.
Finally one +1 for something I proposed :-)
> BUT, I want the build system integrated for users to be able to do this
> flawlessly. I believe maven may be able to help make this happen.
We'll cross that bridge when we get there. Do not forget that users work with a
release, not with the cvs build. And since the release typically doesn't
contain the build.xml file, solving users' problems with the build.xml file is
not the right thing to do.
> maven release add:webdav add:xyz
>
> Of course if webdav and xyz conflicted on something like the web.xml,
> I'm not sure how to handle this...maybe I'm dreaming.
In the meantime, a _very_ good documentation (cookbook like) should be just
fine. IMO maven is not necessary.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
RE: [my philosophy] was RE: MemValueIndexer
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
Wait, admin tool for the build, right? I'm not sure about the build,
specifically deviating from Ant or Maven. Apache throws some heavy
support to those projects. I guess I'm just not familiar with the tools
you suggest.
If you <really> want to help out on an administration tool that typical
users will love, checkout the ui-eclipse project under scratchpad. It
is in bad need of an update to Eclipse 2.1 apis and the latest
SolarEclipse. We really need someone that will put some time in and be
to go-to person for Eclipse plug-in apis and fixes. This was an
excellent gui based on Eclipse 2.0, and would really add a great deal to
the project.
How does that sound (I'll beg if need be)?
-Kevin
-----Original Message-----
From: Nicolas Toper [mailto:nicolas.toper@okare.com]
Sent: Thursday, June 05, 2003 12:48 PM
To: xindice-dev@xml.apache.org
Subject: RE: [my philosophy] was RE: MemValueIndexer
OK you're right. Actually I remember that Novell have a swing based
administration tools.
So should I start working on that? A Swing administration tool/debugger?
-----Message d'origine-----
De : Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Envoye : jeudi 5 juin 2003 21:30
A : xindice-dev@xml.apache.org
Objet : RE: [my philosophy] was RE: MemValueIndexer
Jars will generally come from ibiblio, so source code will be the only
thing downloaded. Think if the Apache PMC allowed all projects to do a
hosted web based build system...mass hysteria on resource usage.
On the subject of compatibility, use java and you're compatible ;)
-Kevin
RE: [my philosophy] was RE: MemValueIndexer
Posted by Nicolas Toper <ni...@okare.com>.
OK you're right. Actually I remember that Novell have a swing based
administration tools.
So should I start working on that? A Swing administration tool/debugger?
-----Message d'origine-----
De : Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Envoye : jeudi 5 juin 2003 21:30
A : xindice-dev@xml.apache.org
Objet : RE: [my philosophy] was RE: MemValueIndexer
Jars will generally come from ibiblio, so source code will be the only
thing downloaded. Think if the Apache PMC allowed all projects to do a
hosted web based build system...mass hysteria on resource usage.
On the subject of compatibility, use java and you're compatible ;)
-Kevin
RE: [my philosophy] was RE: MemValueIndexer
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
Jars will generally come from ibiblio, so source code will be the only
thing downloaded. Think if the Apache PMC allowed all projects to do a
hosted web based build system...mass hysteria on resource usage.
On the subject of compatibility, use java and you're compatible ;)
-Kevin
-----Original Message-----
From: Nicolas Toper [mailto:nicolas.toper@okare.com]
Sent: Thursday, June 05, 2003 11:24 AM
To: xindice-dev@xml.apache.org
Subject: RE: [my philosophy] was RE: MemValueIndexer
yes, wa can do it that way but this wouldn"t work as a standalone or
embedded app. Anyway, the easiest solution I think is for the admin tool
to
be web based: easier to develop, to maintain and no compatibility
problem...
I don't see why CPU usage and bandwidth would be higher with the initial
solution: users would only download what they need instead of
downloading
all the adds-ons.
nicoals
-----Message d'origine-----
De : Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Envoye : jeudi 5 juin 2003 20:15
A : xindice-dev@xml.apache.org
Objet : RE: [my philosophy] was RE: MemValueIndexer
I'm not incredibly up on Apache infrastructure, but I think what you are
proposing would be for apache to host the dynamic build, which would be
a no-no. The forrest and maven projects were both built in part to try
and offload the downloading of artifacts due to bandwidth usage (to
mirrors). I believe cpu usage would also fall into this category.
Would it be viable for the user to download your system as a
'bootstrap', then run the build from their own server?
-Kevin Ross
-----Original Message-----
From: Nicolas Toper [mailto:nicolas.toper@okare.com]
Sent: Thursday, June 05, 2003 11:11 AM
To: xindice-dev@xml.apache.org
Subject: RE: [my philosophy] was RE: MemValueIndexer
Hi,
I'm new to this list and an Xindice user for work so I wish to help and
commit regularly some stuff.
It's a good idea to implement addons and make a system for users to
create
some and commit them simply.
My gues for the build system would be a web-interface a la PHPGroupware:
this system is really is I think better than Maven and could be
directly
integrated on the website. What do you think?
If anyone interested, I can do it or work on the query interface
(actually I
need to make one anyway).
Nicolas
-----Message d'origine-----
De : Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Envoye : jeudi 5 juin 2003 20:03
A : xindice-dev@xml.apache.org
Objet : RE: [my philosophy] was RE: MemValueIndexer
I'm +1 for a supported 'addons'.
BUT, I want the build system integrated for users to be able to do this
flawlessly. I believe maven may be able to help make this happen.
For example, I want Xindice with WebDav and XYZ subprojects (addons), I
should be able to build a distro for myself via cmd line (just guessing
here):
maven release add:webdav add:xyz
Of course if webdav and xyz conflicted on something like the web.xml,
I'm not sure how to handle this...maybe I'm dreaming.
It's just a thought. I want to make this overly easy to accomplish for
typical users. Maven, so far, is the easiest build system I've seen
from a user's standpoint.
Speaking of addons, we were talking about 9-12 months ago about a reorg
of the cvs tree to something more standardized. Are we ready?
-Kevin
-----Original Message-----
From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
Sent: Thursday, June 05, 2003 10:48 AM
To: xindice-dev@xml.apache.org
Subject: Re: [my philosophy] was RE: MemValueIndexer
First of all, thanks for the contribution Terry. I _really_ appreciate
it.
> I detect some sarcasm...
just a little bit... :-)
I have absolutely nothing against users' contributions (on the
contrary). I
think it's very valuable but I'm just against putting everything into
the main
trunc at the moment.
I develop/maintain JUnit-addons, which are addons to the main JUnit
code.
Although I have commit rights to the JUnit project I decided to start an
additional project (to avoid putting everything into the main trunc).
Additional features are provided in an additional library and it's not
difficult
to install another library, isn't it?
I proposed a Xindice-addons project on SF but the idea was chilly
received (to
say the least).
> If non-committers feel that their contributions aren't well received,
> especially when the code is of good quality, they will stop
> contributing.
That's because we only have two ways of integrating any donated code:
- the main trunk (maximum honor)
- the scratchpad (maximum dishonor)
> Just because one or the other committer may not use a piece of code,
> doesn't mean the community won't use it, or that it won't turn into a
> valuable enhancement.
absolutely right. And JUnit-addons is used. Just like Xindice-addons
will.
> A commercial xml database is feature rich. We are still on a path to
> remaining feature poor, but with some 'unsupported' stuff in
scratchpad.
first get the features we have _right_. A few months ago, some
committers
thought about rewriting the core and I would love to see this happen.
> eXist users benefit from out-of-the-box, and I believe we loose some
> people to that project because they can download, unzip, and run the
> startup script. Whallah, xml database.
Gianugo planned to integrate Jetty but I don't know the status of this
task. It
would be really nice to have this done (+ manual).
> same. In addition, it starts up with a pleasant looking cocoon-based
> admin interface, with query ability.
Looks like nobody was/is willing to step up and replace the "Ugly Debug
Tool!"
with something more friendly. I would really like to see a good
embedded admin
client. So who's taking this?
> How would the Xindice community react if the
> eXist community was interested in joining forces?
apart from the licensing, I have no objection.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
RE: [my philosophy] was RE: MemValueIndexer
Posted by Nicolas Toper <ni...@okare.com>.
yes, wa can do it that way but this wouldn"t work as a standalone or
embedded app. Anyway, the easiest solution I think is for the admin tool to
be web based: easier to develop, to maintain and no compatibility problem...
I don't see why CPU usage and bandwidth would be higher with the initial
solution: users would only download what they need instead of downloading
all the adds-ons.
nicoals
-----Message d'origine-----
De : Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Envoye : jeudi 5 juin 2003 20:15
A : xindice-dev@xml.apache.org
Objet : RE: [my philosophy] was RE: MemValueIndexer
I'm not incredibly up on Apache infrastructure, but I think what you are
proposing would be for apache to host the dynamic build, which would be
a no-no. The forrest and maven projects were both built in part to try
and offload the downloading of artifacts due to bandwidth usage (to
mirrors). I believe cpu usage would also fall into this category.
Would it be viable for the user to download your system as a
'bootstrap', then run the build from their own server?
-Kevin Ross
-----Original Message-----
From: Nicolas Toper [mailto:nicolas.toper@okare.com]
Sent: Thursday, June 05, 2003 11:11 AM
To: xindice-dev@xml.apache.org
Subject: RE: [my philosophy] was RE: MemValueIndexer
Hi,
I'm new to this list and an Xindice user for work so I wish to help and
commit regularly some stuff.
It's a good idea to implement addons and make a system for users to
create
some and commit them simply.
My gues for the build system would be a web-interface a la PHPGroupware:
this system is really is I think better than Maven and could be
directly
integrated on the website. What do you think?
If anyone interested, I can do it or work on the query interface
(actually I
need to make one anyway).
Nicolas
-----Message d'origine-----
De : Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Envoye : jeudi 5 juin 2003 20:03
A : xindice-dev@xml.apache.org
Objet : RE: [my philosophy] was RE: MemValueIndexer
I'm +1 for a supported 'addons'.
BUT, I want the build system integrated for users to be able to do this
flawlessly. I believe maven may be able to help make this happen.
For example, I want Xindice with WebDav and XYZ subprojects (addons), I
should be able to build a distro for myself via cmd line (just guessing
here):
maven release add:webdav add:xyz
Of course if webdav and xyz conflicted on something like the web.xml,
I'm not sure how to handle this...maybe I'm dreaming.
It's just a thought. I want to make this overly easy to accomplish for
typical users. Maven, so far, is the easiest build system I've seen
from a user's standpoint.
Speaking of addons, we were talking about 9-12 months ago about a reorg
of the cvs tree to something more standardized. Are we ready?
-Kevin
-----Original Message-----
From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
Sent: Thursday, June 05, 2003 10:48 AM
To: xindice-dev@xml.apache.org
Subject: Re: [my philosophy] was RE: MemValueIndexer
First of all, thanks for the contribution Terry. I _really_ appreciate
it.
> I detect some sarcasm...
just a little bit... :-)
I have absolutely nothing against users' contributions (on the
contrary). I
think it's very valuable but I'm just against putting everything into
the main
trunc at the moment.
I develop/maintain JUnit-addons, which are addons to the main JUnit
code.
Although I have commit rights to the JUnit project I decided to start an
additional project (to avoid putting everything into the main trunc).
Additional features are provided in an additional library and it's not
difficult
to install another library, isn't it?
I proposed a Xindice-addons project on SF but the idea was chilly
received (to
say the least).
> If non-committers feel that their contributions aren't well received,
> especially when the code is of good quality, they will stop
> contributing.
That's because we only have two ways of integrating any donated code:
- the main trunk (maximum honor)
- the scratchpad (maximum dishonor)
> Just because one or the other committer may not use a piece of code,
> doesn't mean the community won't use it, or that it won't turn into a
> valuable enhancement.
absolutely right. And JUnit-addons is used. Just like Xindice-addons
will.
> A commercial xml database is feature rich. We are still on a path to
> remaining feature poor, but with some 'unsupported' stuff in
scratchpad.
first get the features we have _right_. A few months ago, some
committers
thought about rewriting the core and I would love to see this happen.
> eXist users benefit from out-of-the-box, and I believe we loose some
> people to that project because they can download, unzip, and run the
> startup script. Whallah, xml database.
Gianugo planned to integrate Jetty but I don't know the status of this
task. It
would be really nice to have this done (+ manual).
> same. In addition, it starts up with a pleasant looking cocoon-based
> admin interface, with query ability.
Looks like nobody was/is willing to step up and replace the "Ugly Debug
Tool!"
with something more friendly. I would really like to see a good
embedded admin
client. So who's taking this?
> How would the Xindice community react if the
> eXist community was interested in joining forces?
apart from the licensing, I have no objection.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
RE: [my philosophy] was RE: MemValueIndexer
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
I'm not incredibly up on Apache infrastructure, but I think what you are
proposing would be for apache to host the dynamic build, which would be
a no-no. The forrest and maven projects were both built in part to try
and offload the downloading of artifacts due to bandwidth usage (to
mirrors). I believe cpu usage would also fall into this category.
Would it be viable for the user to download your system as a
'bootstrap', then run the build from their own server?
-Kevin Ross
-----Original Message-----
From: Nicolas Toper [mailto:nicolas.toper@okare.com]
Sent: Thursday, June 05, 2003 11:11 AM
To: xindice-dev@xml.apache.org
Subject: RE: [my philosophy] was RE: MemValueIndexer
Hi,
I'm new to this list and an Xindice user for work so I wish to help and
commit regularly some stuff.
It's a good idea to implement addons and make a system for users to
create
some and commit them simply.
My gues for the build system would be a web-interface a la PHPGroupware:
this system is really is I think better than Maven and could be
directly
integrated on the website. What do you think?
If anyone interested, I can do it or work on the query interface
(actually I
need to make one anyway).
Nicolas
-----Message d'origine-----
De : Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Envoye : jeudi 5 juin 2003 20:03
A : xindice-dev@xml.apache.org
Objet : RE: [my philosophy] was RE: MemValueIndexer
I'm +1 for a supported 'addons'.
BUT, I want the build system integrated for users to be able to do this
flawlessly. I believe maven may be able to help make this happen.
For example, I want Xindice with WebDav and XYZ subprojects (addons), I
should be able to build a distro for myself via cmd line (just guessing
here):
maven release add:webdav add:xyz
Of course if webdav and xyz conflicted on something like the web.xml,
I'm not sure how to handle this...maybe I'm dreaming.
It's just a thought. I want to make this overly easy to accomplish for
typical users. Maven, so far, is the easiest build system I've seen
from a user's standpoint.
Speaking of addons, we were talking about 9-12 months ago about a reorg
of the cvs tree to something more standardized. Are we ready?
-Kevin
-----Original Message-----
From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
Sent: Thursday, June 05, 2003 10:48 AM
To: xindice-dev@xml.apache.org
Subject: Re: [my philosophy] was RE: MemValueIndexer
First of all, thanks for the contribution Terry. I _really_ appreciate
it.
> I detect some sarcasm...
just a little bit... :-)
I have absolutely nothing against users' contributions (on the
contrary). I
think it's very valuable but I'm just against putting everything into
the main
trunc at the moment.
I develop/maintain JUnit-addons, which are addons to the main JUnit
code.
Although I have commit rights to the JUnit project I decided to start an
additional project (to avoid putting everything into the main trunc).
Additional features are provided in an additional library and it's not
difficult
to install another library, isn't it?
I proposed a Xindice-addons project on SF but the idea was chilly
received (to
say the least).
> If non-committers feel that their contributions aren't well received,
> especially when the code is of good quality, they will stop
> contributing.
That's because we only have two ways of integrating any donated code:
- the main trunk (maximum honor)
- the scratchpad (maximum dishonor)
> Just because one or the other committer may not use a piece of code,
> doesn't mean the community won't use it, or that it won't turn into a
> valuable enhancement.
absolutely right. And JUnit-addons is used. Just like Xindice-addons
will.
> A commercial xml database is feature rich. We are still on a path to
> remaining feature poor, but with some 'unsupported' stuff in
scratchpad.
first get the features we have _right_. A few months ago, some
committers
thought about rewriting the core and I would love to see this happen.
> eXist users benefit from out-of-the-box, and I believe we loose some
> people to that project because they can download, unzip, and run the
> startup script. Whallah, xml database.
Gianugo planned to integrate Jetty but I don't know the status of this
task. It
would be really nice to have this done (+ manual).
> same. In addition, it starts up with a pleasant looking cocoon-based
> admin interface, with query ability.
Looks like nobody was/is willing to step up and replace the "Ugly Debug
Tool!"
with something more friendly. I would really like to see a good
embedded admin
client. So who's taking this?
> How would the Xindice community react if the
> eXist community was interested in joining forces?
apart from the licensing, I have no objection.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
RE: [my philosophy] was RE: MemValueIndexer
Posted by Nicolas Toper <ni...@okare.com>.
Hi,
I'm new to this list and an Xindice user for work so I wish to help and
commit regularly some stuff.
It's a good idea to implement addons and make a system for users to create
some and commit them simply.
My gues for the build system would be a web-interface a la PHPGroupware:
this system is really is I think better than Maven and could be directly
integrated on the website. What do you think?
If anyone interested, I can do it or work on the query interface (actually I
need to make one anyway).
Nicolas
-----Message d'origine-----
De : Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Envoye : jeudi 5 juin 2003 20:03
A : xindice-dev@xml.apache.org
Objet : RE: [my philosophy] was RE: MemValueIndexer
I'm +1 for a supported 'addons'.
BUT, I want the build system integrated for users to be able to do this
flawlessly. I believe maven may be able to help make this happen.
For example, I want Xindice with WebDav and XYZ subprojects (addons), I
should be able to build a distro for myself via cmd line (just guessing
here):
maven release add:webdav add:xyz
Of course if webdav and xyz conflicted on something like the web.xml,
I'm not sure how to handle this...maybe I'm dreaming.
It's just a thought. I want to make this overly easy to accomplish for
typical users. Maven, so far, is the easiest build system I've seen
from a user's standpoint.
Speaking of addons, we were talking about 9-12 months ago about a reorg
of the cvs tree to something more standardized. Are we ready?
-Kevin
-----Original Message-----
From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
Sent: Thursday, June 05, 2003 10:48 AM
To: xindice-dev@xml.apache.org
Subject: Re: [my philosophy] was RE: MemValueIndexer
First of all, thanks for the contribution Terry. I _really_ appreciate
it.
> I detect some sarcasm...
just a little bit... :-)
I have absolutely nothing against users' contributions (on the
contrary). I
think it's very valuable but I'm just against putting everything into
the main
trunc at the moment.
I develop/maintain JUnit-addons, which are addons to the main JUnit
code.
Although I have commit rights to the JUnit project I decided to start an
additional project (to avoid putting everything into the main trunc).
Additional features are provided in an additional library and it's not
difficult
to install another library, isn't it?
I proposed a Xindice-addons project on SF but the idea was chilly
received (to
say the least).
> If non-committers feel that their contributions aren't well received,
> especially when the code is of good quality, they will stop
> contributing.
That's because we only have two ways of integrating any donated code:
- the main trunk (maximum honor)
- the scratchpad (maximum dishonor)
> Just because one or the other committer may not use a piece of code,
> doesn't mean the community won't use it, or that it won't turn into a
> valuable enhancement.
absolutely right. And JUnit-addons is used. Just like Xindice-addons
will.
> A commercial xml database is feature rich. We are still on a path to
> remaining feature poor, but with some 'unsupported' stuff in
scratchpad.
first get the features we have _right_. A few months ago, some
committers
thought about rewriting the core and I would love to see this happen.
> eXist users benefit from out-of-the-box, and I believe we loose some
> people to that project because they can download, unzip, and run the
> startup script. Whallah, xml database.
Gianugo planned to integrate Jetty but I don't know the status of this
task. It
would be really nice to have this done (+ manual).
> same. In addition, it starts up with a pleasant looking cocoon-based
> admin interface, with query ability.
Looks like nobody was/is willing to step up and replace the "Ugly Debug
Tool!"
with something more friendly. I would really like to see a good
embedded admin
client. So who's taking this?
> How would the Xindice community react if the
> eXist community was interested in joining forces?
apart from the licensing, I have no objection.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
RE: [my philosophy] was RE: MemValueIndexer
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
I'm +1 for a supported 'addons'.
BUT, I want the build system integrated for users to be able to do this
flawlessly. I believe maven may be able to help make this happen.
For example, I want Xindice with WebDav and XYZ subprojects (addons), I
should be able to build a distro for myself via cmd line (just guessing
here):
maven release add:webdav add:xyz
Of course if webdav and xyz conflicted on something like the web.xml,
I'm not sure how to handle this...maybe I'm dreaming.
It's just a thought. I want to make this overly easy to accomplish for
typical users. Maven, so far, is the easiest build system I've seen
from a user's standpoint.
Speaking of addons, we were talking about 9-12 months ago about a reorg
of the cvs tree to something more standardized. Are we ready?
-Kevin
-----Original Message-----
From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
Sent: Thursday, June 05, 2003 10:48 AM
To: xindice-dev@xml.apache.org
Subject: Re: [my philosophy] was RE: MemValueIndexer
First of all, thanks for the contribution Terry. I _really_ appreciate
it.
> I detect some sarcasm...
just a little bit... :-)
I have absolutely nothing against users' contributions (on the
contrary). I
think it's very valuable but I'm just against putting everything into
the main
trunc at the moment.
I develop/maintain JUnit-addons, which are addons to the main JUnit
code.
Although I have commit rights to the JUnit project I decided to start an
additional project (to avoid putting everything into the main trunc).
Additional features are provided in an additional library and it's not
difficult
to install another library, isn't it?
I proposed a Xindice-addons project on SF but the idea was chilly
received (to
say the least).
> If non-committers feel that their contributions aren't well received,
> especially when the code is of good quality, they will stop
> contributing.
That's because we only have two ways of integrating any donated code:
- the main trunk (maximum honor)
- the scratchpad (maximum dishonor)
> Just because one or the other committer may not use a piece of code,
> doesn't mean the community won't use it, or that it won't turn into a
> valuable enhancement.
absolutely right. And JUnit-addons is used. Just like Xindice-addons
will.
> A commercial xml database is feature rich. We are still on a path to
> remaining feature poor, but with some 'unsupported' stuff in
scratchpad.
first get the features we have _right_. A few months ago, some
committers
thought about rewriting the core and I would love to see this happen.
> eXist users benefit from out-of-the-box, and I believe we loose some
> people to that project because they can download, unzip, and run the
> startup script. Whallah, xml database.
Gianugo planned to integrate Jetty but I don't know the status of this
task. It
would be really nice to have this done (+ manual).
> same. In addition, it starts up with a pleasant looking cocoon-based
> admin interface, with query ability.
Looks like nobody was/is willing to step up and replace the "Ugly Debug
Tool!"
with something more friendly. I would really like to see a good
embedded admin
client. So who's taking this?
> How would the Xindice community react if the
> eXist community was interested in joining forces?
apart from the licensing, I have no objection.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
Re: [my philosophy] was RE: MemValueIndexer
Posted by "Vladimir R. Bossicard" <vl...@apache.org>.
First of all, thanks for the contribution Terry. I _really_ appreciate it.
> I detect some sarcasm...
just a little bit... :-)
I have absolutely nothing against users' contributions (on the contrary). I
think it's very valuable but I'm just against putting everything into the main
trunc at the moment.
I develop/maintain JUnit-addons, which are addons to the main JUnit code.
Although I have commit rights to the JUnit project I decided to start an
additional project (to avoid putting everything into the main trunc).
Additional features are provided in an additional library and it's not difficult
to install another library, isn't it?
I proposed a Xindice-addons project on SF but the idea was chilly received (to
say the least).
> If non-committers feel that their contributions aren't well received,
> especially when the code is of good quality, they will stop
> contributing.
That's because we only have two ways of integrating any donated code:
- the main trunk (maximum honor)
- the scratchpad (maximum dishonor)
> Just because one or the other committer may not use a piece of code,
> doesn't mean the community won't use it, or that it won't turn into a
> valuable enhancement.
absolutely right. And JUnit-addons is used. Just like Xindice-addons will.
> A commercial xml database is feature rich. We are still on a path to
> remaining feature poor, but with some 'unsupported' stuff in scratchpad.
first get the features we have _right_. A few months ago, some committers
thought about rewriting the core and I would love to see this happen.
> eXist users benefit from out-of-the-box, and I believe we loose some
> people to that project because they can download, unzip, and run the
> startup script. Whallah, xml database.
Gianugo planned to integrate Jetty but I don't know the status of this task. It
would be really nice to have this done (+ manual).
> same. In addition, it starts up with a pleasant looking cocoon-based
> admin interface, with query ability.
Looks like nobody was/is willing to step up and replace the "Ugly Debug Tool!"
with something more friendly. I would really like to see a good embedded admin
client. So who's taking this?
> How would the Xindice community react if the
> eXist community was interested in joining forces?
apart from the licensing, I have no objection.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
[my philosophy] was RE: MemValueIndexer
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
I detect some sarcasm...
My philosophy:
Too many commits kill an open source community due to bugs.
Too few commits kill an open source community due to lack of progress
(where we are). A perfect example: Jakarta commons. Those projects are
exploding with incredible communities.
If non-committers feel that their contributions aren't well received,
especially when the code is of good quality, they will stop
contributing.
Just because one or the other committer may not use a piece of code,
doesn't mean the community won't use it, or that it won't turn into a
valuable enhancement.
Scratchpad projects are only used by developers devoted to knowing an
open source project intimately. If we want the community to use
something, it must be in the main trunk, or it must be a main
subproject. Scratchpad == not supported.
A commercial xml database is feature rich. We are still on a path to
remaining feature poor, but with some 'unsupported' stuff in scratchpad.
This project needs to work out of the box, either standalone or as a
webapp, or as embedded, and it needs to be full featured.
eXist users benefit from out-of-the-box, and I believe we loose some
people to that project because they can download, unzip, and run the
startup script. Whallah, xml database. We are very prepared to do the
same. In addition, it starts up with a pleasant looking cocoon-based
admin interface, with query ability.
Ok, enough of my rant. What other ideas are out there to help grow the
community involvement? How would the Xindice community react if the
eXist community was interested in joining forces?
-Kevin Ross
-----Original Message-----
From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
Sent: Thursday, June 05, 2003 9:05 AM
To: xindice-dev@xml.apache.org
Subject: RE: MemValueIndexer
> I'm +1 for adding these to the main trunk. If there are no
objections,
> I'll do so.
Xindice absolutely needs some more code in the main trunk because we
have far
too few code to manage. It's getting boring since we don't have bugs
anymore,
users are happy, the releases are going well...
-> scratchpad
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
RE: MemValueIndexer
Posted by "Vladimir R. Bossicard" <vl...@apache.org>.
> I'm +1 for adding these to the main trunk. If there are no objections,
> I'll do so.
Xindice absolutely needs some more code in the main trunk because we have far
too few code to manage. It's getting boring since we don't have bugs anymore,
users are happy, the releases are going well...
-> scratchpad
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
RE: MemValueIndexer
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
Hi Terry,
I'm not a db guru by any means...but...tell me if my idea is correct.
Your classes would seem to be very useful in the case where the db
engine implemented some sort of profiling, and wanted to add an index on
the fly, correct? This would be somewhat analogous to the way the
hotspot VM goes native with heavily traveled byte code?
How do you specifically apply these classes in your applications?
I'm +1 for adding these to the main trunk. If there are no objections,
I'll do so.
-Kevin Ross
-----Original Message-----
From: Terry Rosenbaum [mailto:Terry@amicas.com]
Sent: Thursday, June 05, 2003 1:26 AM
To: xindice-dev@xml.apache.org
Subject: MemValueIndexer
Attached are a couple of classes that you may find
useful. Not a major piece of work, but I'm donating these
to the cause if anyone is interested in checking them in as part
of Xindice.
Attachments:
1) MemValueIndexer.java
* Provides an in-memory implementation of Xindice Indexer
* based upon the Java TreeSet class. This implementation
* is not persistent. A MemValueIndexer is useful for indexing
* of temporary Collections (e.g. those based on MemFiler). It is also
* useful for temporary indexing of persistent Collections.
Note that this indexer stores values as Java objects. Comparisons
are performed using Java comparison. This indexer correctly handles
comparisons of signed values for numeric index types, etc. (unlike
existing ValueIndexer).
2) SizeableMemFiler.java
A Filer which is a wrapper around the Java HashMap.
Just like existing MemFiler except that the initial size
of the HashMap is set via System property named
"org.apache.xindice.core.filer.SizeableMemFiler.INITIAL_SIZE".
Using these 2 classes together, you can run Xindice
as an in-memory database (non-persistent).