|
Seems like an unnecessary restriction to me. It is very easy to
do something like
synchronized( ldc ) {
ldc.setInputStream( is );
ldc.setOutputStream( os );
}
in a client that wants to set both of them. There may be a case
where a client does not want to set both at the same time, and we would
be preventing that by combining the two.
The two examples I've looked into (SASL and StartTLS) do not
involve a real client making those calls; they are made by middleware (SASL)
code or by other parts of the LDAP class library itself (StartTLS). An
implementation of the class library may have a combined method as described
for internal operations or even for external clients if it sees a benefit
to it.
Rob
Steve Sonntag wrote:
So shouldn't both the input stream
and the output stream be setin one atomic operation
so it is thread safe? -Steve
>>> Rob Weltman <robw@worldspot.com> 05-Dec-00 2:45:14 PM >>>
"Kurt D. Zeilenga" wrote:
>
> At 10:45 AM 12/5/00 -0800, Rob Weltman wrote:
> >Steve Sonntag wrote:
> >> I have been trying to figure out how the set/get inputStream
& OutputStreammethods should be used in the LDAPConnection class.
Thedocument states: Added getInputStream()getOutputStream(), setInputStream()
> >>(4.6.36), and setOutputStream(). They are used when establishing
> >>a security layer with SASL, and may also be used to interpose a
> >>proxy. A few comments. and questions: 1) I don't ever
see a case where one would set the input stream andnot also set the outputstream.
If this is true, then the method shouldset both of them, as setting them
individually is inherently not thread safe. 2) Does it ever make sense
to set these values on a connection"in progress"? Is there an intent
that the existing stream classes besubclassed to add encryption or other
functionality?Or does it only make sense to change the streams onlyafter
the connect and before the bind or the first operation? 3) I don't ever
see an application using the existing input/outputstreams directly on a
connection in progresss - i.e., trying to readon the input stream - that
could cause great confusion in the APIas the reader thread in the api and
the application contend forinput data. Rather they would only be
used to create sub classesthat extend their functionality. Am I on
the right track here? -Steve
> >
> >
> > The only use we've had for the methods so far is on SASL
bind, where the result of the operation may be a new security layer. In
that case, both input and output streams are replaced.
>
> Wouldn't you also need to replace them upon StartTLS?
>
> Kurt
Probably. But I haven't looked into the implementation of StartTLS
yet.
Rob
|