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 "Vladimir R. Bossicard" <vl...@apache.org> on 2002/11/27 19:55:40 UTC
Xindice 1.1
Hi guys,
before jumping to 2.0 (very exiting...) could we first wrap up the 1.1
release? There are still several things to do, like:
- finding out how to make a release
- fixing the bugs
- verifying the examples
I know it's less fancy than the 2.0 but if we don't do it, the 1.1 will
get lost.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
Re: Xindice 1.1 (XMLObjects)
Posted by Jim Wissner <ji...@jbrix.org>.
At 10:05 PM 12/3/2002 +0100, you wrote:
>Jim Wissner wrote:
>>Yes, very true. As another data point, I've found another project to use
>>Xindice on, this time as a single-user "embedded" XML store. I just
>>create a Database instance and make calls right to that. Works
>>positively beautifully. I think it's important to make this point. A
>>couple weeks back someone mentioned that they couldn't imagine Xindice
>>being used on the client side, or that using it as anything other than a
>>web service didn't make sense. Can't remember the exact quote. But I can
>>tell you that's incorrect - in fact it works very, very well on the
>>client side.
>
>Sound cool. But I'm not getting why you want to use a Database on an
>embedded system which mimicks a filesystem. Is there any performance gain
>against plain filesystem and XPath queries or is it just a matter of
>"comfort" since everything is already made?
Several reasons. First, simplicity. I can make queries for a specific set
of nodes across a set of documents, without having to implement that
functionality myself. It's very convenient. Second, the automatic
compression/decompression of XML. Next, everything is all in one
conceptual place, the db root, and is less likely to be messed with by
users outside the context of the app, than if there are just a bunch or raw
XML files laying around.
Basically, yes, could be done with filesystem alone. But xindice just
abstracts away a few very nice features so I don't need to do it
myself. Then when things such as access control are there, I've got that too.
Jim
>>I would go so far as to say, keeping the web services modular would allow
>>the Xindice "core" to be kept very lean, for embedded applications, and
>>then on the server side you can plug in the "service module" of choice:
>>xml-rpc, soap, etc. Whatever suits your needs. That would make this one
>>seriously flexible XML system.
>
>Amen. Makes a lot of sense.
>
>Ciao,
>
>--
>Gianugo Rabellino
--
jim@jbrix.org
Visit www.jbrix.org for:
+ SpeedJAVA jEdit Code Completion Plugin
+ Xybrix XML Application Framework
+ other great Open Source Software
Re: Xindice 1.1 (XMLObjects)
Posted by Gianugo Rabellino <gi...@apache.org>.
Jim Wissner wrote:
>
> Yes, very true. As another data point, I've found another project to
> use Xindice on, this time as a single-user "embedded" XML store. I just
> create a Database instance and make calls right to that. Works
> positively beautifully. I think it's important to make this point. A
> couple weeks back someone mentioned that they couldn't imagine Xindice
> being used on the client side, or that using it as anything other than a
> web service didn't make sense. Can't remember the exact quote. But I
> can tell you that's incorrect - in fact it works very, very well on the
> client side.
Sound cool. But I'm not getting why you want to use a Database on an
embedded system which mimicks a filesystem. Is there any performance
gain against plain filesystem and XPath queries or is it just a matter
of "comfort" since everything is already made?
> I would go so far as to say, keeping the web services modular would
> allow the Xindice "core" to be kept very lean, for embedded
> applications, and then on the server side you can plug in the "service
> module" of choice: xml-rpc, soap, etc. Whatever suits your needs. That
> would make this one seriously flexible XML system.
Amen. Makes a lot of sense.
Ciao,
--
Gianugo Rabellino
RE: Xindice 1.1 (XMLObjects)
Posted by Stefan Lischke <li...@novacom.net>.
Hi,
> I would go so far as to say, keeping the web services modular would allow
> the Xindice "core" to be kept very lean, for embedded applications, and
> then on the server side you can plug in the "service module" of choice:
> xml-rpc, soap, etc. Whatever suits your needs. That would make this one
> seriously flexible XML system.
Really Good Point,
I'm working on a project, where i need a flexible XML System in J2ME (Java 2
MicroEdition for MobilePhones and PDA's). If Xindice will be so flexible i
could port just the "core" without xml-rpc, soap .......
By the way is someone working on a J2ME Xindice Port? I would be interested!
I know the MIDP-Profile is not very good, but yesterday MIDP2.0 was released
and everyone is waiting for the PDA Profile
mfg stefan
RE: Xindice 1.1 (XMLObjects)
Posted by Jim Wissner <ji...@jbrix.org>.
Yes, very true. As another data point, I've found another project to use
Xindice on, this time as a single-user "embedded" XML store. I just create
a Database instance and make calls right to that. Works positively
beautifully. I think it's important to make this point. A couple weeks
back someone mentioned that they couldn't imagine Xindice being used on the
client side, or that using it as anything other than a web service didn't
make sense. Can't remember the exact quote. But I can tell you that's
incorrect - in fact it works very, very well on the client side.
I would go so far as to say, keeping the web services modular would allow
the Xindice "core" to be kept very lean, for embedded applications, and
then on the server side you can plug in the "service module" of choice:
xml-rpc, soap, etc. Whatever suits your needs. That would make this one
seriously flexible XML system.
FWIW.
Jim
At 05:04 PM 12/3/2002 +0100, you wrote:
>Hi,
>
> > single-user automated storage facility that makes use of
> > XMLObjects to move
> > documents from one collection to another for archiving as well as a few
> > other functions. Not much code, fast, and very handy!
> >
> > As for how many people are using them, I have no idea.
>
>And not to forget, u can use the internal Xindice Api instead of XML:DB...
>
>mfg stefan
--
jim@jbrix.org
Visit www.jbrix.org for:
+ SpeedJAVA jEdit Code Completion Plugin
+ Xybrix XML Application Framework
+ other great Open Source Software
Re: Xindice 1.1
Posted by Gianugo Rabellino <gi...@apache.org>.
Kurt Ward wrote:
> They provide a method of creating something similar to stored procedures, a
> handsome
> addition to any DB server ;-) They could also be the foundation for
> triggers and other
> server side additions to Xindice.
>
> I have been using Xindice 1.0 in production for a company since 4/4/02 as a
> single-user automated storage facility that makes use of XMLObjects to move
> documents from one collection to another for archiving as well as a few
> other functions. Not much code, fast, and very handy!
>
> As for how many people are using them, I have no idea. There was some
> discussion of them on the users list some time back. At one point there was
> a bug that would not allow them to execute. Not sure if this was fixed in
> 1.0 or not, but I could take a look.
OK, given all the messages on the topic, I'm sold on XMLObjects. :-) Now
all we need is someone able to dig into the code and understand the
implications in porting them from Xindice 1.0. If you could take a look
it would be great: ATM I'm quite busy in catching up after a whole year
of almost total silence (still impressed every day for the work that has
been done, even if I still feel a bit lost...).
Ciao,
--
Gianugo Rabellino
RE: Xindice 1.1 (XMLObjects)
Posted by Stefan Lischke <li...@novacom.net>.
Hi,
> single-user automated storage facility that makes use of
> XMLObjects to move
> documents from one collection to another for archiving as well as a few
> other functions. Not much code, fast, and very handy!
>
> As for how many people are using them, I have no idea.
And not to forget, u can use the internal Xindice Api instead of XML:DB...
mfg stefan
Re: Xindice 1.1
Posted by Kurt Ward <ku...@yahoo.com>.
They provide a method of creating something similar to stored procedures, a
handsome
addition to any DB server ;-) They could also be the foundation for
triggers and other
server side additions to Xindice.
I have been using Xindice 1.0 in production for a company since 4/4/02 as a
single-user automated storage facility that makes use of XMLObjects to move
documents from one collection to another for archiving as well as a few
other functions. Not much code, fast, and very handy!
As for how many people are using them, I have no idea. There was some
discussion of them on the users list some time back. At one point there was
a bug that would not allow them to execute. Not sure if this was fixed in
1.0 or not, but I could take a look.
Kurt
----- Original Message -----
From: "Gianugo Rabellino" <gi...@apache.org>
To: <xi...@xml.apache.org>
Sent: Tuesday, December 03, 2002 5:02 AM
Subject: Re: Xindice 1.1
> Kurt Ward wrote:
> > There is another issue of 1.1 that may or may not create havoc with our
> > current users: XMLObjects (or lack thereof). We need to add this back or
> > create a viable replacement, if not for 1.1, but for sure a 1.2+ (keep
in
> > mind that this is what was originally planned to drive things such as
> > triggers, etc.).
>
> Do you have an idea of how many people is actually using the XMLObject
> code on 1.0? I didn't really find a good use case for them, and in my
> understanding almost nobody is using them ATM. I think that a much more
> useful feature would be adding support for BinayResources, so I'd rather
> work on that.
>
> Anyway, I don't even know why they were removed, and how painful would
> be to bring them in again. Do you have any idea?
>
> > If we can manage to get into the "release often" way of things, we
should
> > not have a problem stepping the product up to the level that everyone
wants
> > (and needs) it to be. Do we vote on moving the XMLObject code back into
the
> > tree or create another solution entirely?
>
> I'd like to have some good use cases for XMLObjects first, so that I can
> finally understand how they will be useful to the end user.
>
> Ciao,
>
> --
> Gianugo Rabellino
Re: Xindice 1.1
Posted by Gianugo Rabellino <gi...@apache.org>.
Kurt Ward wrote:
> There is another issue of 1.1 that may or may not create havoc with our
> current users: XMLObjects (or lack thereof). We need to add this back or
> create a viable replacement, if not for 1.1, but for sure a 1.2+ (keep in
> mind that this is what was originally planned to drive things such as
> triggers, etc.).
Do you have an idea of how many people is actually using the XMLObject
code on 1.0? I didn't really find a good use case for them, and in my
understanding almost nobody is using them ATM. I think that a much more
useful feature would be adding support for BinayResources, so I'd rather
work on that.
Anyway, I don't even know why they were removed, and how painful would
be to bring them in again. Do you have any idea?
> If we can manage to get into the "release often" way of things, we should
> not have a problem stepping the product up to the level that everyone wants
> (and needs) it to be. Do we vote on moving the XMLObject code back into the
> tree or create another solution entirely?
I'd like to have some good use cases for XMLObjects first, so that I can
finally understand how they will be useful to the end user.
Ciao,
--
Gianugo Rabellino
Re: Xindice 1.1
Posted by Kurt Ward <ku...@yahoo.com>.
There is another issue of 1.1 that may or may not create havoc with our
current users: XMLObjects (or lack thereof). We need to add this back or
create a viable replacement, if not for 1.1, but for sure a 1.2+ (keep in
mind that this is what was originally planned to drive things such as
triggers, etc.).
If we can manage to get into the "release often" way of things, we should
not have a problem stepping the product up to the level that everyone wants
(and needs) it to be. Do we vote on moving the XMLObject code back into the
tree or create another solution entirely?
Kurt
----- Original Message -----
From: "Vladimir R. Bossicard" <vl...@apache.org>
To: "Xindice Dev" <xi...@xml.apache.org>
Sent: Wednesday, November 27, 2002 1:55 PM
Subject: Xindice 1.1
> Hi guys,
>
> before jumping to 2.0 (very exiting...) could we first wrap up the 1.1
> release? There are still several things to do, like:
>
> - finding out how to make a release
> - fixing the bugs
> - verifying the examples
>
> I know it's less fancy than the 2.0 but if we don't do it, the 1.1 will
> get lost.
>
> -Vladimir
>
> --
> Vladimir R. Bossicard
> Apache Xindice - http://xml.apache.org/xindice
>
RE: Xindice 1.1
Posted by Matt Liotta <ml...@r337.com>.
> Now that's hard. :-) Anyone with outstanding bugs out there?
>
We have several bugs right now with Xindice 1.0. We are in the process
of updating to the CVS version and will let the list know what bugs
remain unresolved. We also hope to fix some of them ourselves, so we may
just be sending patches. Time will tell...
-Matt
Re: Xindice 1.1
Posted by Gianugo Rabellino <gi...@apache.org>.
Vladimir R. Bossicard wrote:
> before jumping to 2.0 (very exiting...) could we first wrap up the 1.1
> release?
Definitely, you're right.
> There are still several things to do, like:
>
> - finding out how to make a release
I can take care of that if it's OK to you all. I need to get some
documents back from my archive, but I kinda remember the steps that were
needed.
> - fixing the bugs
Now that's hard. :-) Anyone with outstanding bugs out there?
> I know it's less fancy than the 2.0 but if we don't do it, the 1.1 will
> get lost.
Absolutely so.
Ciao,
--
Gianugo Rabellino
XNode API online
Posted by Murray Altheim <m....@open.ac.uk>.
I've posted the XNode API docs at
http://kmi.open.ac.uk/projects/ceryle/doc/api/
in particular are org.apache.xnode.* (the API) and
org.ceryle.xnode.* (my implementation of it). Vladimir has
suggested that I move the tree from org.apache.xnode.* to
org.apache.xindicex.xnode.*. Other suggestions have included
adding the ability to add metadata at the Collection level.
Comments welcome.
Thanks!
Murray
......................................................................
Murray Altheim <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK
If you're the first person in a new territory,
you're likely to get shot at.
-- ma