I've just started incorporating the changes in the streams stuff into
the app I am working on and thought now might be a good time to bring up
a few things. I'll assume the current cvs tree might not yet be
complete?
(1) OutputDataStream - a helpful addition would be able to treat the
OutputDataStream as if it were a java.io.OutputStream. In one case, I
XSLT transform a document to an java.io.OutputStream, it would make
sense to parse to the output stream used by the sendMSG. From an API
viewpoint, a constructor along the lines of
OutputDataStream(java.io.OutputStream) would be nice.
In another point in my app, I send a file as the payload of a message.
Under the current cvs, I believe I would need to read this file into a
byte[] and then use the byte[] to construct a ByteDataStream. In this
case I would rather buffer read the file and write to an
OutputDataStream. The sendMSG would pump the data until the
OutputDataStream were closed (or setComplete()). The old
org.beepcore.beep.core.FileDataStream was actually great for this.
(2) Should Session.fireEvent be public instead of protected - I have an
app class that has registered to listen for channel SessionEvents on a
given session. When a new channel is started on the session I would
like to have my app receive the CHANNEL_OPENED_EVENT_CODE.
I would like to have my StartChannelListener.startChannel fire the event
using
channel.getSession().fireEvent(SessionEvent.CHANNEL_OPENED_EVENT_CODE,channel);
... but Session.fireEvent is protected.
It seems to me that StartChannelListener.startChannel() is the
appropriate place to fire this event on behalf of the session (vs having
the session class fire the event), giving flexibility in the event data
up to the programmer (in my case passing off a reference to the channel
being created).
tom
|
