You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Jacek Kopecky <ja...@idoox.com> on 2000/11/03 10:59:12 UTC
Progressive DOM (was: Re: JDOM vs DOM)
Hello all. 8-)
I think we agreed in the IRC discussion that SAX is not the way to go
since handling SOAP is not a stream process.
What I envision is that we build on DOM (maybe using JDOM if it's
really a "universal DOMUtils") and when it's really needed, we can
plug in some other DOM implementation built progressively from a SAX
stream.
This Progressive DOM would keep what has been parsed so far, but it
would not parse more than needed and it could provide us with the
SAX form of the rest. A little example:
<root>
<a/>
<b>
<c/>
</b>
</root>
The PDOM gets an "element <root> started" SAX event and it would know
we have an XML with its document element <root>. When
getFirstChild() is called the PDOM consumes the following event,
"element <a> started" and it would return the node. If every more
complex method is build on such progressive calls as
getFirstChild() is, we could have excellent efficiency if we only need
the first header in a huge message.
Anyway, I can't see any reason for huge headers, only huge bodies
make sense. To handle this nicely the PDOM could have a method that
would terminate the PDOM existence _and_ (this seems important) we
could get the SAX stream from now (or from some point in the XML
file). So we would parse what we need and the final handler (who would
have to know it's the final one) could work efficiently with SAX.
The first thing to implement here would be an API that lets us do the
last step on a normal DOM. Thus we could use a DOM and finish with SAX
when needed and the switch to PDOM would then be seamless.
Any suggestions? Any kind of PDOM already implemented / in progress?
Jacek Kopecky
Idoox
P.S: hope it was clear enough, I sometimes have problems with
expressing myself in an overly complex way, see? 8-)
On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
> Sorry I missed this chat too; had to take my son to the doc (he hit his
> leg and it may have been fractured .. it wasn't).
>
> I read the logs and I see discussion of using JDOM instead of DOM as
> the tree API. I would like to register my early and strong opposition
> to it .. DOM is a standard API as is SAX and I would like to use those
> two. This allows the use of pretty much arbitrary XML tools (like
> alternate parsers for example as has been brought up) and I'm opposed
> to precluding those in favor of a non-standard (albeit more programmer
> friendly) API. This is the life of standards playing .. whether you
> like it or not you gotta do it. Picking and choosing (or embracing and
> extending) would put us in the camp of the evil empire.
>
> I have some recollection of hearing of a religious war on the JDOM/DOM
> topic on the xerces list .. if there are any veterans of that war here
> maybe they could give us the summary (of their side :-))?
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Glen Daniels" <gd...@allaire.com>
> To: <so...@xml.apache.org>
> Sent: Tuesday, October 31, 2000 5:05 PM
> Subject: IRC chat log
>
>
> >
> > Here's today's IRC log. I'm working on the stuff we mentioned, though I
> > need to push it back a day or two due to local insanity here.
> >
> > I'll mail my prototype tomorrow (need to iron out a couple of bugs from the
> > last round of changes).
> >
> > Glen Daniels
> > Allaire Corp
> > Engineering Manager
> > http://www.allaire.com/
> > Building cool stuff for web developers
> >
> >
> >
>
Re: Progressive DOM (was: Re: JDOM vs DOM)
Posted by Jean-Noel Gadreau <jn...@activcard.com>.
I agree with you that SAX doesn't fit well our server's needs. SAX could
be very efficient if there is no real change done to the envelope (just
dispatching for instance to another server the message). If we want to
enable changes to the tree and flexibility to modify the original
document, SAX is going to make it hard (especially if you want to change
the beginning of the message, past the current point).
Our problem to choose the appropriate techonology comes maybe from the
fact that we are trying to cope with 2 different problems (dispatching
messages which requires more speed than flexibility, and processing of
the message (where you serialize, deserialize, ...).
In my company, we were confronted with both and we decided that it was 2
separate tasks, with different constraints that lead to two
implementations. One is optimized for speed but is not really flexible
when it comes to handling the message. The other has this flexibility,
but this adds more cost.
What do you think ?
Jean-Noel
Jacek Kopecky wrote:
>
> What I meant by saying SOAP is not a stream process was that I think
> that nothing but the body can be usefully processed as a stream. If
> anybody shows me a useful and elegant usecase for a big header, I'll
> rethink this, but I myself cannot easily see the need for streaming
> the header information.
> Of course the body of a message can be anything, there SAX might be
> very appreciated and that's why I wanted the function that terminates
> building of the DOM and hands the SAX stream to the handler.
> I don't like the idea of building the whole server around SAX, it
> doesn't fit the server's needs. I also don't think SAX and DOM model
> would get along well in one architecture, so if you want a specific
> server that handles the _whole_ message as a SAX, you can build one
> yourself (reusing some of the Apache code). The "terminate and give me
> SAX" extension I suggested would nicely allow for most of the
> usecases.
> Or wouldn't it? I'm interested in more discussion on this topic.
> Regards,
>
> Jacek Kopecky
> Idoox
>
> On Fri, 3 Nov 2000, Sanjiva Weerawarana wrote:
>
> > This same problem exists in an XSLT processor .. start doing the transform
> > without waiting for the entire doc to come in. They called it incremental
> > DOM I think. I believe Xerces has some such notion too.
> >
> > The implication of your statement is that we would use the DOM APIs
> > in the interfaces and use an implementation that fills the tree
> > incrementally instead of a priori. When I read the last IRC discussion
> > (was there one after Tuesday; if so I forgot to note it down) didn't
> > imply SAX is out. Yes, SOAP RPC is not a stream process, but SOAP
> > messages are carrying some XML to some recipient; there's no way to
> > know a priori whether that's a stream process or not. As such, I would
> > prefer to see a model where *both* SAX and DOM are in and at say
> > deployment time the choice is made as to what should be delivered to
> > the next step. Is that out of the question?
> >
> > Sanjiva.
> >
> > ----- Original Message -----
> > From: "Jacek Kopecky" <ja...@idoox.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, November 03, 2000 4:59 AM
> > Subject: Progressive DOM (was: Re: JDOM vs DOM)
> >
> >
> > > Hello all. 8-)
> > > I think we agreed in the IRC discussion that SAX is not the way to go
> > > since handling SOAP is not a stream process.
> > > What I envision is that we build on DOM (maybe using JDOM if it's
> > > really a "universal DOMUtils") and when it's really needed, we can
> > > plug in some other DOM implementation built progressively from a SAX
> > > stream.
> > > This Progressive DOM would keep what has been parsed so far, but it
> > > would not parse more than needed and it could provide us with the
> > > SAX form of the rest. A little example:
> > >
> > > <root>
> > > <a/>
> > > <b>
> > > <c/>
> > > </b>
> > > </root>
> > >
> > > The PDOM gets an "element <root> started" SAX event and it would know
> > > we have an XML with its document element <root>. When
> > > getFirstChild() is called the PDOM consumes the following event,
> > > "element <a> started" and it would return the node. If every more
> > > complex method is build on such progressive calls as
> > > getFirstChild() is, we could have excellent efficiency if we only need
> > > the first header in a huge message.
> > > Anyway, I can't see any reason for huge headers, only huge bodies
> > > make sense. To handle this nicely the PDOM could have a method that
> > > would terminate the PDOM existence _and_ (this seems important) we
> > > could get the SAX stream from now (or from some point in the XML
> > > file). So we would parse what we need and the final handler (who would
> > > have to know it's the final one) could work efficiently with SAX.
> > >
> > > The first thing to implement here would be an API that lets us do the
> > > last step on a normal DOM. Thus we could use a DOM and finish with SAX
> > > when needed and the switch to PDOM would then be seamless.
> > >
> > > Any suggestions? Any kind of PDOM already implemented / in progress?
> > >
> > > Jacek Kopecky
> > > Idoox
> > >
> > > P.S: hope it was clear enough, I sometimes have problems with
> > > expressing myself in an overly complex way, see? 8-)
> > >
> > >
> > >
> > > On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
> > >
> > > > Sorry I missed this chat too; had to take my son to the doc (he hit his
> > > > leg and it may have been fractured .. it wasn't).
> > > >
> > > > I read the logs and I see discussion of using JDOM instead of DOM as
> > > > the tree API. I would like to register my early and strong opposition
> > > > to it .. DOM is a standard API as is SAX and I would like to use those
> > > > two. This allows the use of pretty much arbitrary XML tools (like
> > > > alternate parsers for example as has been brought up) and I'm opposed
> > > > to precluding those in favor of a non-standard (albeit more programmer
> > > > friendly) API. This is the life of standards playing .. whether you
> > > > like it or not you gotta do it. Picking and choosing (or embracing and
> > > > extending) would put us in the camp of the evil empire.
> > > >
> > > > I have some recollection of hearing of a religious war on the JDOM/DOM
> > > > topic on the xerces list .. if there are any veterans of that war here
> > > > maybe they could give us the summary (of their side :-))?
> > > >
> > > > Sanjiva.
> > > >
> > > > ----- Original Message -----
> > > > From: "Glen Daniels" <gd...@allaire.com>
> > > > To: <so...@xml.apache.org>
> > > > Sent: Tuesday, October 31, 2000 5:05 PM
> > > > Subject: IRC chat log
> > > >
> > > >
> > > > >
> > > > > Here's today's IRC log. I'm working on the stuff we mentioned, though
> > I
> > > > > need to push it back a day or two due to local insanity here.
> > > > >
> > > > > I'll mail my prototype tomorrow (need to iron out a couple of bugs from
> > the
> > > > > last round of changes).
> > > > >
> > > > > Glen Daniels
> > > > > Allaire Corp
> > > > > Engineering Manager
> > > > > http://www.allaire.com/
> > > > > Building cool stuff for web developers
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
Re: Progressive DOM (was: Re: JDOM vs DOM)
Posted by Jean-Noel Gadreau <jn...@activcard.com>.
I agree with you that SAX doesn't fit well our server's needs. SAX could
be very efficient if there is no real change done to the envelope (just
dispatching for instance to another server the message). If we want to
enable changes to the tree and flexibility to modify the original
document, SAX is going to make it hard (especially if you want to change
the beginning of the message, past the current point).
Our problem to choose the appropriate techonology comes maybe from the
fact that we are trying to cope with 2 different problems (dispatching
messages which requires more speed than flexibility, and processing of
the message (where you serialize, deserialize, ...).
In my company, we were confronted with both and we decided that it was 2
separate tasks, with different constraints that lead to two
implementations. One is optimized for speed but is not really flexible
when it comes to handling the message. The other has this flexibility,
but this adds more cost.
What do you think ?
Jean-Noel
Jacek Kopecky wrote:
>
> What I meant by saying SOAP is not a stream process was that I think
> that nothing but the body can be usefully processed as a stream. If
> anybody shows me a useful and elegant usecase for a big header, I'll
> rethink this, but I myself cannot easily see the need for streaming
> the header information.
> Of course the body of a message can be anything, there SAX might be
> very appreciated and that's why I wanted the function that terminates
> building of the DOM and hands the SAX stream to the handler.
> I don't like the idea of building the whole server around SAX, it
> doesn't fit the server's needs. I also don't think SAX and DOM model
> would get along well in one architecture, so if you want a specific
> server that handles the _whole_ message as a SAX, you can build one
> yourself (reusing some of the Apache code). The "terminate and give me
> SAX" extension I suggested would nicely allow for most of the
> usecases.
> Or wouldn't it? I'm interested in more discussion on this topic.
> Regards,
>
> Jacek Kopecky
> Idoox
>
> On Fri, 3 Nov 2000, Sanjiva Weerawarana wrote:
>
> > This same problem exists in an XSLT processor .. start doing the transform
> > without waiting for the entire doc to come in. They called it incremental
> > DOM I think. I believe Xerces has some such notion too.
> >
> > The implication of your statement is that we would use the DOM APIs
> > in the interfaces and use an implementation that fills the tree
> > incrementally instead of a priori. When I read the last IRC discussion
> > (was there one after Tuesday; if so I forgot to note it down) didn't
> > imply SAX is out. Yes, SOAP RPC is not a stream process, but SOAP
> > messages are carrying some XML to some recipient; there's no way to
> > know a priori whether that's a stream process or not. As such, I would
> > prefer to see a model where *both* SAX and DOM are in and at say
> > deployment time the choice is made as to what should be delivered to
> > the next step. Is that out of the question?
> >
> > Sanjiva.
> >
> > ----- Original Message -----
> > From: "Jacek Kopecky" <ja...@idoox.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, November 03, 2000 4:59 AM
> > Subject: Progressive DOM (was: Re: JDOM vs DOM)
> >
> >
> > > Hello all. 8-)
> > > I think we agreed in the IRC discussion that SAX is not the way to go
> > > since handling SOAP is not a stream process.
> > > What I envision is that we build on DOM (maybe using JDOM if it's
> > > really a "universal DOMUtils") and when it's really needed, we can
> > > plug in some other DOM implementation built progressively from a SAX
> > > stream.
> > > This Progressive DOM would keep what has been parsed so far, but it
> > > would not parse more than needed and it could provide us with the
> > > SAX form of the rest. A little example:
> > >
> > > <root>
> > > <a/>
> > > <b>
> > > <c/>
> > > </b>
> > > </root>
> > >
> > > The PDOM gets an "element <root> started" SAX event and it would know
> > > we have an XML with its document element <root>. When
> > > getFirstChild() is called the PDOM consumes the following event,
> > > "element <a> started" and it would return the node. If every more
> > > complex method is build on such progressive calls as
> > > getFirstChild() is, we could have excellent efficiency if we only need
> > > the first header in a huge message.
> > > Anyway, I can't see any reason for huge headers, only huge bodies
> > > make sense. To handle this nicely the PDOM could have a method that
> > > would terminate the PDOM existence _and_ (this seems important) we
> > > could get the SAX stream from now (or from some point in the XML
> > > file). So we would parse what we need and the final handler (who would
> > > have to know it's the final one) could work efficiently with SAX.
> > >
> > > The first thing to implement here would be an API that lets us do the
> > > last step on a normal DOM. Thus we could use a DOM and finish with SAX
> > > when needed and the switch to PDOM would then be seamless.
> > >
> > > Any suggestions? Any kind of PDOM already implemented / in progress?
> > >
> > > Jacek Kopecky
> > > Idoox
> > >
> > > P.S: hope it was clear enough, I sometimes have problems with
> > > expressing myself in an overly complex way, see? 8-)
> > >
> > >
> > >
> > > On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
> > >
> > > > Sorry I missed this chat too; had to take my son to the doc (he hit his
> > > > leg and it may have been fractured .. it wasn't).
> > > >
> > > > I read the logs and I see discussion of using JDOM instead of DOM as
> > > > the tree API. I would like to register my early and strong opposition
> > > > to it .. DOM is a standard API as is SAX and I would like to use those
> > > > two. This allows the use of pretty much arbitrary XML tools (like
> > > > alternate parsers for example as has been brought up) and I'm opposed
> > > > to precluding those in favor of a non-standard (albeit more programmer
> > > > friendly) API. This is the life of standards playing .. whether you
> > > > like it or not you gotta do it. Picking and choosing (or embracing and
> > > > extending) would put us in the camp of the evil empire.
> > > >
> > > > I have some recollection of hearing of a religious war on the JDOM/DOM
> > > > topic on the xerces list .. if there are any veterans of that war here
> > > > maybe they could give us the summary (of their side :-))?
> > > >
> > > > Sanjiva.
> > > >
> > > > ----- Original Message -----
> > > > From: "Glen Daniels" <gd...@allaire.com>
> > > > To: <so...@xml.apache.org>
> > > > Sent: Tuesday, October 31, 2000 5:05 PM
> > > > Subject: IRC chat log
> > > >
> > > >
> > > > >
> > > > > Here's today's IRC log. I'm working on the stuff we mentioned, though
> > I
> > > > > need to push it back a day or two due to local insanity here.
> > > > >
> > > > > I'll mail my prototype tomorrow (need to iron out a couple of bugs from
> > the
> > > > > last round of changes).
> > > > >
> > > > > Glen Daniels
> > > > > Allaire Corp
> > > > > Engineering Manager
> > > > > http://www.allaire.com/
> > > > > Building cool stuff for web developers
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
Re: Progressive DOM (was: Re: JDOM vs DOM)
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
This combined DOM/SAX approach makes a lot of sense - it gives the advantages of
efficient SAX parsing for the body while retaining the flexibility of working with a
(J)DOM for the headers. The idea of building a DOM for the whole message and then
passing the body portion off to a handler (which would then need to walk the DOM and
convert all the values to usable form) had me concerned about performance, but this
way the message handler can decide how to process the body itself. Those who want to
work with a DOM-type model for the body can easily build one from the SAX event
stream, while others can handle value conversions on the fly and avoid some overhead.
I personally prefer JDOM to DOM but haven't seen any actual comparisons of
performance (CPU and memory usage). JDOM *is* compatible with DOM in the sense that
it supports two-way conversion. I don't know if this support is complete, but it
offers the possibility of using JDOM internally while still being able to provide a
DOM representation if that's really what someone wants to work with.
- Dennis
Jacek Kopecky wrote:
> What I meant by saying SOAP is not a stream process was that I think
> that nothing but the body can be usefully processed as a stream. If
> anybody shows me a useful and elegant usecase for a big header, I'll
> rethink this, but I myself cannot easily see the need for streaming
> the header information.
> Of course the body of a message can be anything, there SAX might be
> very appreciated and that's why I wanted the function that terminates
> building of the DOM and hands the SAX stream to the handler.
> I don't like the idea of building the whole server around SAX, it
> doesn't fit the server's needs. I also don't think SAX and DOM model
> would get along well in one architecture, so if you want a specific
> server that handles the _whole_ message as a SAX, you can build one
> yourself (reusing some of the Apache code). The "terminate and give me
> SAX" extension I suggested would nicely allow for most of the
> usecases.
> Or wouldn't it? I'm interested in more discussion on this topic.
> Regards,
>
> Jacek Kopecky
> Idoox
>
> On Fri, 3 Nov 2000, Sanjiva Weerawarana wrote:
>
> > This same problem exists in an XSLT processor .. start doing the transform
> > without waiting for the entire doc to come in. They called it incremental
> > DOM I think. I believe Xerces has some such notion too.
> >
> > The implication of your statement is that we would use the DOM APIs
> > in the interfaces and use an implementation that fills the tree
> > incrementally instead of a priori. When I read the last IRC discussion
> > (was there one after Tuesday; if so I forgot to note it down) didn't
> > imply SAX is out. Yes, SOAP RPC is not a stream process, but SOAP
> > messages are carrying some XML to some recipient; there's no way to
> > know a priori whether that's a stream process or not. As such, I would
> > prefer to see a model where *both* SAX and DOM are in and at say
> > deployment time the choice is made as to what should be delivered to
> > the next step. Is that out of the question?
> >
> > Sanjiva.
> >
> > ----- Original Message -----
> > From: "Jacek Kopecky" <ja...@idoox.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, November 03, 2000 4:59 AM
> > Subject: Progressive DOM (was: Re: JDOM vs DOM)
> >
> >
> > > Hello all. 8-)
> > > I think we agreed in the IRC discussion that SAX is not the way to go
> > > since handling SOAP is not a stream process.
> > > What I envision is that we build on DOM (maybe using JDOM if it's
> > > really a "universal DOMUtils") and when it's really needed, we can
> > > plug in some other DOM implementation built progressively from a SAX
> > > stream.
> > > This Progressive DOM would keep what has been parsed so far, but it
> > > would not parse more than needed and it could provide us with the
> > > SAX form of the rest. A little example:
> > >
> > > <root>
> > > <a/>
> > > <b>
> > > <c/>
> > > </b>
> > > </root>
> > >
> > > The PDOM gets an "element <root> started" SAX event and it would know
> > > we have an XML with its document element <root>. When
> > > getFirstChild() is called the PDOM consumes the following event,
> > > "element <a> started" and it would return the node. If every more
> > > complex method is build on such progressive calls as
> > > getFirstChild() is, we could have excellent efficiency if we only need
> > > the first header in a huge message.
> > > Anyway, I can't see any reason for huge headers, only huge bodies
> > > make sense. To handle this nicely the PDOM could have a method that
> > > would terminate the PDOM existence _and_ (this seems important) we
> > > could get the SAX stream from now (or from some point in the XML
> > > file). So we would parse what we need and the final handler (who would
> > > have to know it's the final one) could work efficiently with SAX.
> > >
> > > The first thing to implement here would be an API that lets us do the
> > > last step on a normal DOM. Thus we could use a DOM and finish with SAX
> > > when needed and the switch to PDOM would then be seamless.
> > >
> > > Any suggestions? Any kind of PDOM already implemented / in progress?
> > >
> > > Jacek Kopecky
> > > Idoox
> > >
> > > P.S: hope it was clear enough, I sometimes have problems with
> > > expressing myself in an overly complex way, see? 8-)
> > >
> > >
> > >
> > > On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
> > >
> > > > Sorry I missed this chat too; had to take my son to the doc (he hit his
> > > > leg and it may have been fractured .. it wasn't).
> > > >
> > > > I read the logs and I see discussion of using JDOM instead of DOM as
> > > > the tree API. I would like to register my early and strong opposition
> > > > to it .. DOM is a standard API as is SAX and I would like to use those
> > > > two. This allows the use of pretty much arbitrary XML tools (like
> > > > alternate parsers for example as has been brought up) and I'm opposed
> > > > to precluding those in favor of a non-standard (albeit more programmer
> > > > friendly) API. This is the life of standards playing .. whether you
> > > > like it or not you gotta do it. Picking and choosing (or embracing and
> > > > extending) would put us in the camp of the evil empire.
> > > >
> > > > I have some recollection of hearing of a religious war on the JDOM/DOM
> > > > topic on the xerces list .. if there are any veterans of that war here
> > > > maybe they could give us the summary (of their side :-))?
> > > >
> > > > Sanjiva.
> > > >
> > > > ----- Original Message -----
> > > > From: "Glen Daniels" <gd...@allaire.com>
> > > > To: <so...@xml.apache.org>
> > > > Sent: Tuesday, October 31, 2000 5:05 PM
> > > > Subject: IRC chat log
> > > >
> > > >
> > > > >
> > > > > Here's today's IRC log. I'm working on the stuff we mentioned, though
> > I
> > > > > need to push it back a day or two due to local insanity here.
> > > > >
> > > > > I'll mail my prototype tomorrow (need to iron out a couple of bugs from
> > the
> > > > > last round of changes).
> > > > >
> > > > > Glen Daniels
> > > > > Allaire Corp
> > > > > Engineering Manager
> > > > > http://www.allaire.com/
> > > > > Building cool stuff for web developers
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
Re: Progressive DOM (was: Re: JDOM vs DOM)
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
This combined DOM/SAX approach makes a lot of sense - it gives the advantages of
efficient SAX parsing for the body while retaining the flexibility of working with a
(J)DOM for the headers. The idea of building a DOM for the whole message and then
passing the body portion off to a handler (which would then need to walk the DOM and
convert all the values to usable form) had me concerned about performance, but this
way the message handler can decide how to process the body itself. Those who want to
work with a DOM-type model for the body can easily build one from the SAX event
stream, while others can handle value conversions on the fly and avoid some overhead.
I personally prefer JDOM to DOM but haven't seen any actual comparisons of
performance (CPU and memory usage). JDOM *is* compatible with DOM in the sense that
it supports two-way conversion. I don't know if this support is complete, but it
offers the possibility of using JDOM internally while still being able to provide a
DOM representation if that's really what someone wants to work with.
- Dennis
Jacek Kopecky wrote:
> What I meant by saying SOAP is not a stream process was that I think
> that nothing but the body can be usefully processed as a stream. If
> anybody shows me a useful and elegant usecase for a big header, I'll
> rethink this, but I myself cannot easily see the need for streaming
> the header information.
> Of course the body of a message can be anything, there SAX might be
> very appreciated and that's why I wanted the function that terminates
> building of the DOM and hands the SAX stream to the handler.
> I don't like the idea of building the whole server around SAX, it
> doesn't fit the server's needs. I also don't think SAX and DOM model
> would get along well in one architecture, so if you want a specific
> server that handles the _whole_ message as a SAX, you can build one
> yourself (reusing some of the Apache code). The "terminate and give me
> SAX" extension I suggested would nicely allow for most of the
> usecases.
> Or wouldn't it? I'm interested in more discussion on this topic.
> Regards,
>
> Jacek Kopecky
> Idoox
>
> On Fri, 3 Nov 2000, Sanjiva Weerawarana wrote:
>
> > This same problem exists in an XSLT processor .. start doing the transform
> > without waiting for the entire doc to come in. They called it incremental
> > DOM I think. I believe Xerces has some such notion too.
> >
> > The implication of your statement is that we would use the DOM APIs
> > in the interfaces and use an implementation that fills the tree
> > incrementally instead of a priori. When I read the last IRC discussion
> > (was there one after Tuesday; if so I forgot to note it down) didn't
> > imply SAX is out. Yes, SOAP RPC is not a stream process, but SOAP
> > messages are carrying some XML to some recipient; there's no way to
> > know a priori whether that's a stream process or not. As such, I would
> > prefer to see a model where *both* SAX and DOM are in and at say
> > deployment time the choice is made as to what should be delivered to
> > the next step. Is that out of the question?
> >
> > Sanjiva.
> >
> > ----- Original Message -----
> > From: "Jacek Kopecky" <ja...@idoox.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, November 03, 2000 4:59 AM
> > Subject: Progressive DOM (was: Re: JDOM vs DOM)
> >
> >
> > > Hello all. 8-)
> > > I think we agreed in the IRC discussion that SAX is not the way to go
> > > since handling SOAP is not a stream process.
> > > What I envision is that we build on DOM (maybe using JDOM if it's
> > > really a "universal DOMUtils") and when it's really needed, we can
> > > plug in some other DOM implementation built progressively from a SAX
> > > stream.
> > > This Progressive DOM would keep what has been parsed so far, but it
> > > would not parse more than needed and it could provide us with the
> > > SAX form of the rest. A little example:
> > >
> > > <root>
> > > <a/>
> > > <b>
> > > <c/>
> > > </b>
> > > </root>
> > >
> > > The PDOM gets an "element <root> started" SAX event and it would know
> > > we have an XML with its document element <root>. When
> > > getFirstChild() is called the PDOM consumes the following event,
> > > "element <a> started" and it would return the node. If every more
> > > complex method is build on such progressive calls as
> > > getFirstChild() is, we could have excellent efficiency if we only need
> > > the first header in a huge message.
> > > Anyway, I can't see any reason for huge headers, only huge bodies
> > > make sense. To handle this nicely the PDOM could have a method that
> > > would terminate the PDOM existence _and_ (this seems important) we
> > > could get the SAX stream from now (or from some point in the XML
> > > file). So we would parse what we need and the final handler (who would
> > > have to know it's the final one) could work efficiently with SAX.
> > >
> > > The first thing to implement here would be an API that lets us do the
> > > last step on a normal DOM. Thus we could use a DOM and finish with SAX
> > > when needed and the switch to PDOM would then be seamless.
> > >
> > > Any suggestions? Any kind of PDOM already implemented / in progress?
> > >
> > > Jacek Kopecky
> > > Idoox
> > >
> > > P.S: hope it was clear enough, I sometimes have problems with
> > > expressing myself in an overly complex way, see? 8-)
> > >
> > >
> > >
> > > On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
> > >
> > > > Sorry I missed this chat too; had to take my son to the doc (he hit his
> > > > leg and it may have been fractured .. it wasn't).
> > > >
> > > > I read the logs and I see discussion of using JDOM instead of DOM as
> > > > the tree API. I would like to register my early and strong opposition
> > > > to it .. DOM is a standard API as is SAX and I would like to use those
> > > > two. This allows the use of pretty much arbitrary XML tools (like
> > > > alternate parsers for example as has been brought up) and I'm opposed
> > > > to precluding those in favor of a non-standard (albeit more programmer
> > > > friendly) API. This is the life of standards playing .. whether you
> > > > like it or not you gotta do it. Picking and choosing (or embracing and
> > > > extending) would put us in the camp of the evil empire.
> > > >
> > > > I have some recollection of hearing of a religious war on the JDOM/DOM
> > > > topic on the xerces list .. if there are any veterans of that war here
> > > > maybe they could give us the summary (of their side :-))?
> > > >
> > > > Sanjiva.
> > > >
> > > > ----- Original Message -----
> > > > From: "Glen Daniels" <gd...@allaire.com>
> > > > To: <so...@xml.apache.org>
> > > > Sent: Tuesday, October 31, 2000 5:05 PM
> > > > Subject: IRC chat log
> > > >
> > > >
> > > > >
> > > > > Here's today's IRC log. I'm working on the stuff we mentioned, though
> > I
> > > > > need to push it back a day or two due to local insanity here.
> > > > >
> > > > > I'll mail my prototype tomorrow (need to iron out a couple of bugs from
> > the
> > > > > last round of changes).
> > > > >
> > > > > Glen Daniels
> > > > > Allaire Corp
> > > > > Engineering Manager
> > > > > http://www.allaire.com/
> > > > > Building cool stuff for web developers
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
Re: Progressive DOM (was: Re: JDOM vs DOM)
Posted by Jacek Kopecky <ja...@idoox.com>.
What I meant by saying SOAP is not a stream process was that I think
that nothing but the body can be usefully processed as a stream. If
anybody shows me a useful and elegant usecase for a big header, I'll
rethink this, but I myself cannot easily see the need for streaming
the header information.
Of course the body of a message can be anything, there SAX might be
very appreciated and that's why I wanted the function that terminates
building of the DOM and hands the SAX stream to the handler.
I don't like the idea of building the whole server around SAX, it
doesn't fit the server's needs. I also don't think SAX and DOM model
would get along well in one architecture, so if you want a specific
server that handles the _whole_ message as a SAX, you can build one
yourself (reusing some of the Apache code). The "terminate and give me
SAX" extension I suggested would nicely allow for most of the
usecases.
Or wouldn't it? I'm interested in more discussion on this topic.
Regards,
Jacek Kopecky
Idoox
On Fri, 3 Nov 2000, Sanjiva Weerawarana wrote:
> This same problem exists in an XSLT processor .. start doing the transform
> without waiting for the entire doc to come in. They called it incremental
> DOM I think. I believe Xerces has some such notion too.
>
> The implication of your statement is that we would use the DOM APIs
> in the interfaces and use an implementation that fills the tree
> incrementally instead of a priori. When I read the last IRC discussion
> (was there one after Tuesday; if so I forgot to note it down) didn't
> imply SAX is out. Yes, SOAP RPC is not a stream process, but SOAP
> messages are carrying some XML to some recipient; there's no way to
> know a priori whether that's a stream process or not. As such, I would
> prefer to see a model where *both* SAX and DOM are in and at say
> deployment time the choice is made as to what should be delivered to
> the next step. Is that out of the question?
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Jacek Kopecky" <ja...@idoox.com>
> To: <so...@xml.apache.org>
> Sent: Friday, November 03, 2000 4:59 AM
> Subject: Progressive DOM (was: Re: JDOM vs DOM)
>
>
> > Hello all. 8-)
> > I think we agreed in the IRC discussion that SAX is not the way to go
> > since handling SOAP is not a stream process.
> > What I envision is that we build on DOM (maybe using JDOM if it's
> > really a "universal DOMUtils") and when it's really needed, we can
> > plug in some other DOM implementation built progressively from a SAX
> > stream.
> > This Progressive DOM would keep what has been parsed so far, but it
> > would not parse more than needed and it could provide us with the
> > SAX form of the rest. A little example:
> >
> > <root>
> > <a/>
> > <b>
> > <c/>
> > </b>
> > </root>
> >
> > The PDOM gets an "element <root> started" SAX event and it would know
> > we have an XML with its document element <root>. When
> > getFirstChild() is called the PDOM consumes the following event,
> > "element <a> started" and it would return the node. If every more
> > complex method is build on such progressive calls as
> > getFirstChild() is, we could have excellent efficiency if we only need
> > the first header in a huge message.
> > Anyway, I can't see any reason for huge headers, only huge bodies
> > make sense. To handle this nicely the PDOM could have a method that
> > would terminate the PDOM existence _and_ (this seems important) we
> > could get the SAX stream from now (or from some point in the XML
> > file). So we would parse what we need and the final handler (who would
> > have to know it's the final one) could work efficiently with SAX.
> >
> > The first thing to implement here would be an API that lets us do the
> > last step on a normal DOM. Thus we could use a DOM and finish with SAX
> > when needed and the switch to PDOM would then be seamless.
> >
> > Any suggestions? Any kind of PDOM already implemented / in progress?
> >
> > Jacek Kopecky
> > Idoox
> >
> > P.S: hope it was clear enough, I sometimes have problems with
> > expressing myself in an overly complex way, see? 8-)
> >
> >
> >
> > On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
> >
> > > Sorry I missed this chat too; had to take my son to the doc (he hit his
> > > leg and it may have been fractured .. it wasn't).
> > >
> > > I read the logs and I see discussion of using JDOM instead of DOM as
> > > the tree API. I would like to register my early and strong opposition
> > > to it .. DOM is a standard API as is SAX and I would like to use those
> > > two. This allows the use of pretty much arbitrary XML tools (like
> > > alternate parsers for example as has been brought up) and I'm opposed
> > > to precluding those in favor of a non-standard (albeit more programmer
> > > friendly) API. This is the life of standards playing .. whether you
> > > like it or not you gotta do it. Picking and choosing (or embracing and
> > > extending) would put us in the camp of the evil empire.
> > >
> > > I have some recollection of hearing of a religious war on the JDOM/DOM
> > > topic on the xerces list .. if there are any veterans of that war here
> > > maybe they could give us the summary (of their side :-))?
> > >
> > > Sanjiva.
> > >
> > > ----- Original Message -----
> > > From: "Glen Daniels" <gd...@allaire.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Tuesday, October 31, 2000 5:05 PM
> > > Subject: IRC chat log
> > >
> > >
> > > >
> > > > Here's today's IRC log. I'm working on the stuff we mentioned, though
> I
> > > > need to push it back a day or two due to local insanity here.
> > > >
> > > > I'll mail my prototype tomorrow (need to iron out a couple of bugs from
> the
> > > > last round of changes).
> > > >
> > > > Glen Daniels
> > > > Allaire Corp
> > > > Engineering Manager
> > > > http://www.allaire.com/
> > > > Building cool stuff for web developers
> > > >
> > > >
> > > >
> > >
> >
>
Re: Progressive DOM (was: Re: JDOM vs DOM)
Posted by Jacek Kopecky <ja...@idoox.com>.
What I meant by saying SOAP is not a stream process was that I think
that nothing but the body can be usefully processed as a stream. If
anybody shows me a useful and elegant usecase for a big header, I'll
rethink this, but I myself cannot easily see the need for streaming
the header information.
Of course the body of a message can be anything, there SAX might be
very appreciated and that's why I wanted the function that terminates
building of the DOM and hands the SAX stream to the handler.
I don't like the idea of building the whole server around SAX, it
doesn't fit the server's needs. I also don't think SAX and DOM model
would get along well in one architecture, so if you want a specific
server that handles the _whole_ message as a SAX, you can build one
yourself (reusing some of the Apache code). The "terminate and give me
SAX" extension I suggested would nicely allow for most of the
usecases.
Or wouldn't it? I'm interested in more discussion on this topic.
Regards,
Jacek Kopecky
Idoox
On Fri, 3 Nov 2000, Sanjiva Weerawarana wrote:
> This same problem exists in an XSLT processor .. start doing the transform
> without waiting for the entire doc to come in. They called it incremental
> DOM I think. I believe Xerces has some such notion too.
>
> The implication of your statement is that we would use the DOM APIs
> in the interfaces and use an implementation that fills the tree
> incrementally instead of a priori. When I read the last IRC discussion
> (was there one after Tuesday; if so I forgot to note it down) didn't
> imply SAX is out. Yes, SOAP RPC is not a stream process, but SOAP
> messages are carrying some XML to some recipient; there's no way to
> know a priori whether that's a stream process or not. As such, I would
> prefer to see a model where *both* SAX and DOM are in and at say
> deployment time the choice is made as to what should be delivered to
> the next step. Is that out of the question?
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Jacek Kopecky" <ja...@idoox.com>
> To: <so...@xml.apache.org>
> Sent: Friday, November 03, 2000 4:59 AM
> Subject: Progressive DOM (was: Re: JDOM vs DOM)
>
>
> > Hello all. 8-)
> > I think we agreed in the IRC discussion that SAX is not the way to go
> > since handling SOAP is not a stream process.
> > What I envision is that we build on DOM (maybe using JDOM if it's
> > really a "universal DOMUtils") and when it's really needed, we can
> > plug in some other DOM implementation built progressively from a SAX
> > stream.
> > This Progressive DOM would keep what has been parsed so far, but it
> > would not parse more than needed and it could provide us with the
> > SAX form of the rest. A little example:
> >
> > <root>
> > <a/>
> > <b>
> > <c/>
> > </b>
> > </root>
> >
> > The PDOM gets an "element <root> started" SAX event and it would know
> > we have an XML with its document element <root>. When
> > getFirstChild() is called the PDOM consumes the following event,
> > "element <a> started" and it would return the node. If every more
> > complex method is build on such progressive calls as
> > getFirstChild() is, we could have excellent efficiency if we only need
> > the first header in a huge message.
> > Anyway, I can't see any reason for huge headers, only huge bodies
> > make sense. To handle this nicely the PDOM could have a method that
> > would terminate the PDOM existence _and_ (this seems important) we
> > could get the SAX stream from now (or from some point in the XML
> > file). So we would parse what we need and the final handler (who would
> > have to know it's the final one) could work efficiently with SAX.
> >
> > The first thing to implement here would be an API that lets us do the
> > last step on a normal DOM. Thus we could use a DOM and finish with SAX
> > when needed and the switch to PDOM would then be seamless.
> >
> > Any suggestions? Any kind of PDOM already implemented / in progress?
> >
> > Jacek Kopecky
> > Idoox
> >
> > P.S: hope it was clear enough, I sometimes have problems with
> > expressing myself in an overly complex way, see? 8-)
> >
> >
> >
> > On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
> >
> > > Sorry I missed this chat too; had to take my son to the doc (he hit his
> > > leg and it may have been fractured .. it wasn't).
> > >
> > > I read the logs and I see discussion of using JDOM instead of DOM as
> > > the tree API. I would like to register my early and strong opposition
> > > to it .. DOM is a standard API as is SAX and I would like to use those
> > > two. This allows the use of pretty much arbitrary XML tools (like
> > > alternate parsers for example as has been brought up) and I'm opposed
> > > to precluding those in favor of a non-standard (albeit more programmer
> > > friendly) API. This is the life of standards playing .. whether you
> > > like it or not you gotta do it. Picking and choosing (or embracing and
> > > extending) would put us in the camp of the evil empire.
> > >
> > > I have some recollection of hearing of a religious war on the JDOM/DOM
> > > topic on the xerces list .. if there are any veterans of that war here
> > > maybe they could give us the summary (of their side :-))?
> > >
> > > Sanjiva.
> > >
> > > ----- Original Message -----
> > > From: "Glen Daniels" <gd...@allaire.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Tuesday, October 31, 2000 5:05 PM
> > > Subject: IRC chat log
> > >
> > >
> > > >
> > > > Here's today's IRC log. I'm working on the stuff we mentioned, though
> I
> > > > need to push it back a day or two due to local insanity here.
> > > >
> > > > I'll mail my prototype tomorrow (need to iron out a couple of bugs from
> the
> > > > last round of changes).
> > > >
> > > > Glen Daniels
> > > > Allaire Corp
> > > > Engineering Manager
> > > > http://www.allaire.com/
> > > > Building cool stuff for web developers
> > > >
> > > >
> > > >
> > >
> >
>
Re: Progressive DOM (was: Re: JDOM vs DOM)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
This same problem exists in an XSLT processor .. start doing the transform
without waiting for the entire doc to come in. They called it incremental
DOM I think. I believe Xerces has some such notion too.
The implication of your statement is that we would use the DOM APIs
in the interfaces and use an implementation that fills the tree
incrementally instead of a priori. When I read the last IRC discussion
(was there one after Tuesday; if so I forgot to note it down) didn't
imply SAX is out. Yes, SOAP RPC is not a stream process, but SOAP
messages are carrying some XML to some recipient; there's no way to
know a priori whether that's a stream process or not. As such, I would
prefer to see a model where *both* SAX and DOM are in and at say
deployment time the choice is made as to what should be delivered to
the next step. Is that out of the question?
Sanjiva.
----- Original Message -----
From: "Jacek Kopecky" <ja...@idoox.com>
To: <so...@xml.apache.org>
Sent: Friday, November 03, 2000 4:59 AM
Subject: Progressive DOM (was: Re: JDOM vs DOM)
> Hello all. 8-)
> I think we agreed in the IRC discussion that SAX is not the way to go
> since handling SOAP is not a stream process.
> What I envision is that we build on DOM (maybe using JDOM if it's
> really a "universal DOMUtils") and when it's really needed, we can
> plug in some other DOM implementation built progressively from a SAX
> stream.
> This Progressive DOM would keep what has been parsed so far, but it
> would not parse more than needed and it could provide us with the
> SAX form of the rest. A little example:
>
> <root>
> <a/>
> <b>
> <c/>
> </b>
> </root>
>
> The PDOM gets an "element <root> started" SAX event and it would know
> we have an XML with its document element <root>. When
> getFirstChild() is called the PDOM consumes the following event,
> "element <a> started" and it would return the node. If every more
> complex method is build on such progressive calls as
> getFirstChild() is, we could have excellent efficiency if we only need
> the first header in a huge message.
> Anyway, I can't see any reason for huge headers, only huge bodies
> make sense. To handle this nicely the PDOM could have a method that
> would terminate the PDOM existence _and_ (this seems important) we
> could get the SAX stream from now (or from some point in the XML
> file). So we would parse what we need and the final handler (who would
> have to know it's the final one) could work efficiently with SAX.
>
> The first thing to implement here would be an API that lets us do the
> last step on a normal DOM. Thus we could use a DOM and finish with SAX
> when needed and the switch to PDOM would then be seamless.
>
> Any suggestions? Any kind of PDOM already implemented / in progress?
>
> Jacek Kopecky
> Idoox
>
> P.S: hope it was clear enough, I sometimes have problems with
> expressing myself in an overly complex way, see? 8-)
>
>
>
> On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
>
> > Sorry I missed this chat too; had to take my son to the doc (he hit his
> > leg and it may have been fractured .. it wasn't).
> >
> > I read the logs and I see discussion of using JDOM instead of DOM as
> > the tree API. I would like to register my early and strong opposition
> > to it .. DOM is a standard API as is SAX and I would like to use those
> > two. This allows the use of pretty much arbitrary XML tools (like
> > alternate parsers for example as has been brought up) and I'm opposed
> > to precluding those in favor of a non-standard (albeit more programmer
> > friendly) API. This is the life of standards playing .. whether you
> > like it or not you gotta do it. Picking and choosing (or embracing and
> > extending) would put us in the camp of the evil empire.
> >
> > I have some recollection of hearing of a religious war on the JDOM/DOM
> > topic on the xerces list .. if there are any veterans of that war here
> > maybe they could give us the summary (of their side :-))?
> >
> > Sanjiva.
> >
> > ----- Original Message -----
> > From: "Glen Daniels" <gd...@allaire.com>
> > To: <so...@xml.apache.org>
> > Sent: Tuesday, October 31, 2000 5:05 PM
> > Subject: IRC chat log
> >
> >
> > >
> > > Here's today's IRC log. I'm working on the stuff we mentioned, though
I
> > > need to push it back a day or two due to local insanity here.
> > >
> > > I'll mail my prototype tomorrow (need to iron out a couple of bugs from
the
> > > last round of changes).
> > >
> > > Glen Daniels
> > > Allaire Corp
> > > Engineering Manager
> > > http://www.allaire.com/
> > > Building cool stuff for web developers
> > >
> > >
> > >
> >
>
Re: Progressive DOM (was: Re: JDOM vs DOM)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
This same problem exists in an XSLT processor .. start doing the transform
without waiting for the entire doc to come in. They called it incremental
DOM I think. I believe Xerces has some such notion too.
The implication of your statement is that we would use the DOM APIs
in the interfaces and use an implementation that fills the tree
incrementally instead of a priori. When I read the last IRC discussion
(was there one after Tuesday; if so I forgot to note it down) didn't
imply SAX is out. Yes, SOAP RPC is not a stream process, but SOAP
messages are carrying some XML to some recipient; there's no way to
know a priori whether that's a stream process or not. As such, I would
prefer to see a model where *both* SAX and DOM are in and at say
deployment time the choice is made as to what should be delivered to
the next step. Is that out of the question?
Sanjiva.
----- Original Message -----
From: "Jacek Kopecky" <ja...@idoox.com>
To: <so...@xml.apache.org>
Sent: Friday, November 03, 2000 4:59 AM
Subject: Progressive DOM (was: Re: JDOM vs DOM)
> Hello all. 8-)
> I think we agreed in the IRC discussion that SAX is not the way to go
> since handling SOAP is not a stream process.
> What I envision is that we build on DOM (maybe using JDOM if it's
> really a "universal DOMUtils") and when it's really needed, we can
> plug in some other DOM implementation built progressively from a SAX
> stream.
> This Progressive DOM would keep what has been parsed so far, but it
> would not parse more than needed and it could provide us with the
> SAX form of the rest. A little example:
>
> <root>
> <a/>
> <b>
> <c/>
> </b>
> </root>
>
> The PDOM gets an "element <root> started" SAX event and it would know
> we have an XML with its document element <root>. When
> getFirstChild() is called the PDOM consumes the following event,
> "element <a> started" and it would return the node. If every more
> complex method is build on such progressive calls as
> getFirstChild() is, we could have excellent efficiency if we only need
> the first header in a huge message.
> Anyway, I can't see any reason for huge headers, only huge bodies
> make sense. To handle this nicely the PDOM could have a method that
> would terminate the PDOM existence _and_ (this seems important) we
> could get the SAX stream from now (or from some point in the XML
> file). So we would parse what we need and the final handler (who would
> have to know it's the final one) could work efficiently with SAX.
>
> The first thing to implement here would be an API that lets us do the
> last step on a normal DOM. Thus we could use a DOM and finish with SAX
> when needed and the switch to PDOM would then be seamless.
>
> Any suggestions? Any kind of PDOM already implemented / in progress?
>
> Jacek Kopecky
> Idoox
>
> P.S: hope it was clear enough, I sometimes have problems with
> expressing myself in an overly complex way, see? 8-)
>
>
>
> On Wed, 1 Nov 2000, Sanjiva Weerawarana wrote:
>
> > Sorry I missed this chat too; had to take my son to the doc (he hit his
> > leg and it may have been fractured .. it wasn't).
> >
> > I read the logs and I see discussion of using JDOM instead of DOM as
> > the tree API. I would like to register my early and strong opposition
> > to it .. DOM is a standard API as is SAX and I would like to use those
> > two. This allows the use of pretty much arbitrary XML tools (like
> > alternate parsers for example as has been brought up) and I'm opposed
> > to precluding those in favor of a non-standard (albeit more programmer
> > friendly) API. This is the life of standards playing .. whether you
> > like it or not you gotta do it. Picking and choosing (or embracing and
> > extending) would put us in the camp of the evil empire.
> >
> > I have some recollection of hearing of a religious war on the JDOM/DOM
> > topic on the xerces list .. if there are any veterans of that war here
> > maybe they could give us the summary (of their side :-))?
> >
> > Sanjiva.
> >
> > ----- Original Message -----
> > From: "Glen Daniels" <gd...@allaire.com>
> > To: <so...@xml.apache.org>
> > Sent: Tuesday, October 31, 2000 5:05 PM
> > Subject: IRC chat log
> >
> >
> > >
> > > Here's today's IRC log. I'm working on the stuff we mentioned, though
I
> > > need to push it back a day or two due to local insanity here.
> > >
> > > I'll mail my prototype tomorrow (need to iron out a couple of bugs from
the
> > > last round of changes).
> > >
> > > Glen Daniels
> > > Allaire Corp
> > > Engineering Manager
> > > http://www.allaire.com/
> > > Building cool stuff for web developers
> > >
> > >
> > >
> >
>