Re: Issue 5.1 Wrap-up: SSH End of message directive

[Ed Roskos <ed.roskos@utstar.com>]

Juergen Schoenwaelder wrote:
> > > > > > Ed Roskos writes:
>
>
> Ed> I suppose it has to be invalid XML to meet the 3rd criteria, so we
> Ed> may even get rid of making it look like a processing instruction
> Ed> and go with something a bit easier to see as an end-of-message
> Ed> marker.
>
> Ed> But I personally still believe it is better to use valid XML and
> Ed> to forbid a NetConf agent from generating a CDATA block with the
> Ed> eom embedded in it.  If we go with a non-XML eom, then it
> Ed> discounts the ability to send off a bunch of request documents and
> Ed> a drop-connection and to wrap the whole sequence in an XML element
> Ed> so you can use the sequence of replies in a single document parsed
> Ed> by the original requester.  This allows a single DOM for the
> Ed> replies (if desired for a given application) or to use XSLT on the
> Ed> full set of replies.
>
> I fail to understand your argument here. The <?eom?> marker is there
> only for the SSH mapping because it does not do proper framing.  The
> <?eom?> marker should be inserted when the document hits the SSH
> transport and removed once if comes out of the SSH transport and this
> should be totally transparent for any "higher level" processing of the
> NETCONF XML messages. Note that the NETCONF messages themself continue
> to be XML documents. So if you want to transform NETCONF XML documents
> using XSLT or embed them in another XML document, just do so.

Yeah, that's one use-case, and will be a common one.  But here is
another.

If you need multiple messages in a row to do what you want, an option
if we use valid XML as the EOM is to open the SSH connection, toss out
all of the requests and a drop-connection request (I know NetConf
doesn't define one, but it is useful for this use case), and for the
output string start with an outer-element, read until EOF, suffix the
end-outer-element, and process the single XML document as a whole
rather than incrementally.  Where this may come in handy is if you
need to build up your requests incrementally in a script, but process
the result as a whole.  If doing things programmatically, you may
just go for a DOM built incrementally.  But if you are scripting,
you may just have string templates of the documents into which you
place values for your requests.

This use case is just a convenience we could live without, as you could
add more logic to your script to process each message incrementally
or to combine XSLT and DOM (which requires the writing of the CSS,
even if it may be simple).  But why limit ourselves?  In the end, I am
not religious about either approach, I just think we have a bit more 
flexibility by not limiting ourselves.  When scripting, people like
flexibility.

--
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/>