You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Lars Martin <la...@smb-tec.com> on 2000/09/26 15:21:53 UTC
Future of Crimson package?
Hi all,
some weeks ago somebody was asking about the future of the Crimson package.
This package contains an implementation of a treediff algorithm to find out the
differences between two DOM trees.
We would like to use this software as the basis of the version tracking system
in Prowler - an XML-based Content Management System. While using the software
we've found some bugs that we've fixed and the algorithm works very stable now.
But who is responsible for this code? The last CVS log is over five months old.
Is there a cause for hope that this code will be maintained in the future?
Does exist the intention to provide a tool package? Because we don't need a
second XML parser engine..
Thanks in advance,
Lars
--
___________________________________________________________________
Lars Martin mailto:lars@smb-tec.com
SMB GmbH http://www.smb-tec.com
Re: SAX callback behavior in Xerces 1.03 -- Don't want to wait for buffer to fill.
Posted by Peter Johnson <pe...@kbdnet.net.au>.
Gary,
See the FAQ "How do I read data from a stream as it arrives?". That should
solve your problem.
regards
Peter Johnson
----- Original Message -----
From: "Gary Beaver" <ga...@responsys.com>
To: <xe...@xml.apache.org>
Cc: "Bart Locanthi" <ba...@sabl.com>; <be...@electronhead.com>
Sent: Friday, September 29, 2000 10:20 AM
Subject: SAX callback behavior in Xerces 1.03 -- Don't want to wait for
buffer to fill.
> Hi,
>
> We're trying to use the callback mechanism in SAX to execute code in
> real-time. In our case, our implementation of ContentHandler.endElement
> performs an action when an ending tag is read from an input source. The
> behavior we're seeing is that the parser reads a chunk of characters
before
> invoking the callbacks. From looking at the source code, it appears that
SAX
> reads 16K or EOF before actually parsing the character input.
>
> Is there any way to tell SAX to invoke callbacks when when it has read
> enough characters to invoke a callback and not at some chunk boundary? If
> not, will future versions of Xerces/SAX offer any support in this regard?
>
> We're using the SAX parser in Xerces 1.03, running under JDK1.3.
>
> -- Gary Beaver
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
SAX callback behavior in Xerces 1.03 -- Don't want to wait for buffer to fill.
Posted by Gary Beaver <ga...@responsys.com>.
Hi,
We're trying to use the callback mechanism in SAX to execute code in
real-time. In our case, our implementation of ContentHandler.endElement
performs an action when an ending tag is read from an input source. The
behavior we're seeing is that the parser reads a chunk of characters before
invoking the callbacks. From looking at the source code, it appears that SAX
reads 16K or EOF before actually parsing the character input.
Is there any way to tell SAX to invoke callbacks when when it has read
enough characters to invoke a callback and not at some chunk boundary? If
not, will future versions of Xerces/SAX offer any support in this regard?
We're using the SAX parser in Xerces 1.03, running under JDK1.3.
-- Gary Beaver
tool package [ was Re: Future of Crimson package?]
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Edwin Goei wrote:
>
> Lars Martin wrote:
> >
> > On Don, 28 Sep 2000, you wrote:
> > > So I think the idea of a tool package at apache is great!
> >
> > So let's count the votes ... oh, I'm not a voting commiter ;-)
>
> Sounds good to me. I would suggest that someone make a proposal on what
> to do with the treediff code so others can work on it.
I agree.
> Right now it's
> in the /xml-contrib repository which doesn't have a working cvs
> notification list. Should the code be moved? Or should the
> /xml-contrib repository be fixed? Other options?
I'd say these two questions should be answered independently. Regarding
the notification mechanism on /xml-contrib repository, I think it should
be fixed ASAP. Regarding the tool package, I'd put it somewhere in the
xerces repository. As long as we can agree on where to put it and we
don't add it to the main jar...
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Future of Crimson package?
Posted by James Duncan Davidson <du...@x180.com>.
on 10/4/00 7:38 AM, Lars Martin at lars@smb-tec.com wrote:
> Do you think that it would be a good choice to create an own repository for
> each tool? Today we speak about the xml-treediff package, but what if there is
> the need for other tools as well? What about a "tools" repository that can be
> used by all other Apache projects.
There's tools, then there are tools.
There's been talk of doing a Utility repository for single or multiple class
utilities (like byte buffers, data structures, etc). But for bigger things
that fit into the "tools" catagory, yes, sometimes we have codebases for
them. Like Ant.
.duncan
Re: Future of Crimson package?
Posted by Lars Martin <la...@smb-tec.com>.
Hi,
On Mit, 04 Okt 2000, you wrote:
> Another option is to split it out into /xml-treediff
Do you think that it would be a good choice to create an own repository for
each tool? Today we speak about the xml-treediff package, but what if there is
the need for other tools as well? What about a "tools" repository that can be
used by all other Apache projects.
Lars
--
___________________________________________________________________
Lars Martin mailto:lars@smb-tec.com
SMB GmbH http://www.smb-tec.com
Re: Future of Crimson package?
Posted by James Duncan Davidson <du...@x180.com>.
on 9/28/00 4:41 PM, Edwin Goei at Edwin.Goei@eng.sun.com wrote:
> Sounds good to me. I would suggest that someone make a proposal on what
> to do with the treediff code so others can work on it. Right now it's
> in the /xml-contrib repository which doesn't have a working cvs
> notification list. Should the code be moved? Or should the
> /xml-contrib repository be fixed? Other options?
Another option is to split it out into /xml-treediff
.duncan
Re: Future of Crimson package?
Posted by Edwin Goei <Ed...@eng.sun.com>.
Lars Martin wrote:
>
> On Don, 28 Sep 2000, you wrote:
> > So I think the idea of a tool package at apache is great!
>
> So let's count the votes ... oh, I'm not a voting commiter ;-)
Sounds good to me. I would suggest that someone make a proposal on what
to do with the treediff code so others can work on it. Right now it's
in the /xml-contrib repository which doesn't have a working cvs
notification list. Should the code be moved? Or should the
/xml-contrib repository be fixed? Other options?
-Edwin
Re: Future of Crimson package?
Posted by Lars Martin <la...@smb-tec.com>.
On Don, 28 Sep 2000, you wrote:
> So I think the idea of a tool package at apache is great!
So let's count the votes ... oh, I'm not a voting commiter ;-)
Lars
--
___________________________________________________________________
Lars Martin mailto:lars@smb-tec.com
SMB GmbH http://www.smb-tec.com
Re: Future of Crimson package?
Posted by Thomas Conradi <co...@prostep.de>.
Hi Martin,
I would be intersted in the treediff algorithm as a tool-like form because I would
need it for the same purpose as you do - and still keep Xerces as my parser.
So I think the idea of a tool package at apache is great!
Kind regards, Thomas
Lars Martin wrote:
> Hi all,
>
> some weeks ago somebody was asking about the future of the Crimson package.
> This package contains an implementation of a treediff algorithm to find out the
> differences between two DOM trees.
>
> We would like to use this software as the basis of the version tracking system
> in Prowler - an XML-based Content Management System. While using the software
> we've found some bugs that we've fixed and the algorithm works very stable now.
>
> But who is responsible for this code? The last CVS log is over five months old.
> Is there a cause for hope that this code will be maintained in the future?
>
> Does exist the intention to provide a tool package? Because we don't need a
> second XML parser engine..
>
> Thanks in advance,
> Lars
> --
> ___________________________________________________________________
> Lars Martin mailto:lars@smb-tec.com
> SMB GmbH http://www.smb-tec.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
--
___________________________________________________________________________
ProSTEP GmbH Phone: +49-6151-9287381
Thomas Conradi Fax: +49-6151-9287381
Dolivostr. 11 Email: conradi@prostep.de
D-64293 Darmstadt
___________________________________________________________________________
Re: Future of Crimson package?
Posted by James Duncan Davidson <du...@x180.com>.
on 9/26/00 6:21 AM, Lars Martin at lars@smb-tec.com wrote:
> some weeks ago somebody was asking about the future of the Crimson package.
I've actually taken this question to the XML PMC for resolution.
.duncan