[Standards-JIG] Closing idle streams
Carlo v. Loesch
CvL at mail.symlynX.com
Thu Jun 1 19:38:32 UTC 2006
Peter Saint-Andre typeth:
| But is idleness the only reason to close a stream without explaining why?
Some applications may want to submit a few things, than back out.
Is it so important why an application closes a link, as long as it
does so in a friendly agreeable way? The need to recycle a socket
is not a reason to consider an "error" - it's more like putting a
pen back to pick up a different one. An everyday gesture. Okay this
is stomach logic again here.. ;)
But I thought about your other idea:
| > | It seems more helpful to inform the other side why the stream is being
| > | closed by sending a stream error, rather than sending </stream:stream>
| > | and leaving the other side to wonder why the stream was closed. If that
| > | is true, then it may make sense to relax the rule in 4.7.1 by decoupling
| > | closing of the XML stream from termination of the TCP connection (i.e.,
| > | I wonder if the text really needs to say "MUST close the XML stream and
| > | SHOULD terminate the TCP connection"). Naturally we would need to think
| > | carefully about the consequences of any such change.
I took a quick glance at the list of error conditions, correct me but
aren't they all pretty fatal and the immediate termination of the
socket is a pretty valid requirement there. <connection-timeout/>
sticks a bit out, but if you change the wording to only mean real
timeout errors like many servers are already doing, then the whole
plan makes sense again.
Why does closing a stream regularely have to be considered an error?
More information about the Standards