[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 5.1) SSH End of message directive




By "run-to-completion" it is meant that the entire document must be read before events are generated? I agree that this is the case with DOM parsers, but it is not the case with either a C version of SAX (expat) or a Java version, org.apache.crimson.parser.XMLReaderImpl, and it's certainly not a necessary quality of the SAX API. (Perhaps we're not discussing the same issue?)

Thanks,
Ted.



On Dec 10, 2003, at 12:33 PM, Little, Kevin C (IP) wrote:

Allow me to second Phil on this issue. The
full-session-as-a-single-document approach was an early idea we
"borrowed" (:-) from Junoscript when we began to explore the idea of
XML-based configuration. It was one of the first ideas we threw out,
too, for the reasons Phil mentioned.

-k

-----Original Message-----
From: Phil Shafer [mailto:phil@juniper.net]
Sent: Wednesday, December 10, 2003 2:03 PM
To: Ted Goddard
Cc: netconf@ops.ietf.org; Graham Klyne; Juergen Schoenwaelder
Subject: Re: Issue 5.1) SSH End of message directive

Single document sessions are something we must avoid, IMHO.  The
full-session-as-a-single-document is one a the design decisions
that we made in Junoscript that has been, er, suboptimal.  SAX
parsers are run-to-completion, which forces one to organize the
program around the parser, which is painful if, say, your program
is already organized around some wretched event loop, like libisc
or x11.

Thanks,
 Phil




Ted Goddard writes:

It seems possible that the form of XML adopted by Jabber is much easier to deal with in implementation (there is only one document, so you don't have to continually reset your XML parser) than what we currently have in the SSH draft. Jabber is presently dealing with the same issues, since each jabber message is as discrete as a netconf operation.

Are there any objections to, say,

<netconf>
  <rpc>
   ...
  </rpc>
  <rpc>
  ...
  </rpc>
  ...
</netconf>

(Thanks, Graham, for reminding us to look at Jabber.)

Ted.


On Dec 9, 2003, at 4:52 PM, Ted Goddard wrote:



Jabber takes the approach of making the entire stream a single XML document:

C: <?xml version='1.0'?>
   <stream:stream
       to='example.com'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       version='1.0'>
S: <?xml version='1.0'?>
   <stream:stream
       from='example.com'
       id='someid'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       version='1.0'>
...  encryption, authentication, and resource binding ...
C:   <message from='juliet@example.com'
              to='romeo@example.net'
              xml:lang='en'>
C:     <body>Art thou not Romeo, and a Montague?</body>
C:   </message>
S:   <message from='romeo@example.net'
              to='juliet@example.com'
              xml:lang='en'>
S:     <body>Neither, fair saint, if either thee dislike.</body>
S:   </message>
C: </stream:stream>
S: </stream:stream>

The netconf concept for SSH was to make each operation a standalone
XML document to avoid the artificial opening and closing elements,
but
either way, the parser must feed events to the
application before the input stream is complete.

Ted.

On Dec 7, 2003, at 5:05 AM, Graham Klyne wrote:

I think the Jabber folks have considerable experience in this
area...
what do they do?

#g
--

At 15:19 05/12/03 -0500, Phil Shafer wrote:
Juergen Schoenwaelder writes:
Does everybody feel comfortable to be required to feed the protocol
message directly into an XML parser using a SAX like interface in
order to detect message boundaries?

We've had problems doing this esp in java.


Furthermore, I believe that declarations add value in the long run
and we should not forbit declarations of PIs.

Declarations make an xml parser a couple of orders of magnitude harder to write and at least a couple of orders of magnitude
larger.
Given the diminishing value and use of DTDs, I don't see the win.

If you do need the features of DTDs, you can preprocess your
document
on an external machine and pass the expanded DTD-less data to the
netconf server.

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

------------ Graham Klyne For email:
http://www.ninebynine.org/#Contact


-- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>


-- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>