[standards-jig] JEP 65 - Bytestreams
justin-jdev at affinix.com
Thu Dec 19 01:48:17 UTC 2002
On Wednesday 18 December 2002 04:58 pm, Dave Smith wrote:
> now). Sweeping statements such as "Clients should be prepared for
> anything.." have no business being in a specification.
True, I suppose it is a given when writing a server application. I just threw
it in there as a reminder.
> The difference is that neither the Target or Initiator knows which
> connection to actually use in JEP 46. You can't simply say "the first
> connection". We live in a networked environment and any one of these
> connections may be "the first", depending on who you ask.
This is not a problem in JEP-46. The target and initiator have all of the
information they need to make a decision about which connection is considered
"the first". After all, JEP-65, which can support multiple connections from
one side, does not suffer from this problem either, does it?
> I think the important, distinguishing point here is that 65 provides a
> mechanism for informing the Initiator what StreamHost was used for
> establishing a connection. This puts the onus of selecting one of
> several possible connections on the Target. The Initiator may certainly
> have to listen for connections from the Target, but it doesn't have to
> do anything meaningful with those connections until the Target informs
> it which connection is relevant. JEP 46 has no way to identify the
> connection the Target would prefer to use.
Sure it does. The target needs only to identify itself over the TCP channel.
> The funny thing here is that so far, I have yet to see _anyone_ say
> that they agree with your sentiment about JEP 46's complexity. Even the
> people who seconded the Last Call have noted that 65 is _less_ complex.
And have they said this on the list? Perhaps I missed them. Even so, my
"independent polling" of other developers has shown more preference to
JEP-46. IMO, we need to see some greater discussion on the list from other
client developers before we can make any real assumption about what they
> Having a start-TLS in the stream doesn't make a whole lot of sense to
> me, either. It is not the responsibility of the bytestream layer to
> "simplify" the application protocol. That's assuming way too much about
> how the applications will be utilizing the bytestream. I would note
> that JEP 47 has little to no bearing on this issue (due to the fact
> that it is solving this of data transfer problem in a _completely_
> different way) and as such should not be used as a reason to include an
> encryption layer.
Well, this can be argued either way. I think it is a good idea to consider
other stream protocols (ie, JEP-47) at the same time, so that we come up with
solutions that work together. However, in the interest of getting a
standard, I am willing to go either way.
More information about the Standards