Recent changes to feature-requests

Core objects should be interfaces

Scott J Brickner — Wed, 23 Oct 2002 20:45:59 -0000

Some of the key objects for the system really should be
defined as interfaces, with separate implementations. At
a minimum, Session, Channel, and Message.

As it is, I'm finding it very difficult to write unit tests for
my profiles, since I can't make mock objects to pass in
as test fixtures.

SASL EXTERNAL Profile?

Ben Feinstein — Fri, 20 Jul 2001 21:50:31 -0000

It would be nice to have a SASL EXTERNAL profile that
could use an underlying TLSProfile to authenticate the
Session. For applications using TLS, this would offer
a good way to still use the standard SASL
authentication framework in our applications.

Thanks,
Ben Feinstein

JSSE TLS Algorithm settings?

Ben Feinstein — Fri, 20 Jul 2001 21:48:43 -0000

It would be nice to have the option of setting the
algorithm in the JSSE TLS Profile init(). I know that
it is marked as "not yet implemented" but this is an
important option for applications using TLS.

Thanks,
Ben Feinstein

CVS commit mailings

Dave Golombek — Thu, 07 Jun 2001 19:32:11 -0000

SourceForge makes it pretty easy to set up a mailing
list to receive automatic notification (and diffs) of
each commit made to the project. It'd be pretty cool
if you enabled this, so it's easier for users to get a
feel for what work is being done between releases.

Thanks,
Dave

SourceForge docs at:
https://sourceforge.net/docman/display_doc.php?docid=772&group_id=1

LogService implementation mapping to Log

Dave Golombek — Tue, 15 May 2001 00:15:24 -0000

This is less a feature request than a piece of code
that could be added to examples, showing how to map the
LogService interface onto the Log4J logger (see
http://jakarta.apache.org/log4j\). Just thought it
might be useful to other people, since Log4J seems to
be pretty widely used.

Dave

Session.receiveCloseChannel change

Dave Golombek — Wed, 02 May 2001 06:46:28 -0000

This is probably closer to a bug report, but it's a bug
against the BEEP protocol, so I'll phrase it as a
feature request. According to RFC3080 Section 2.3.1.3,
a beep peer is allowed to reject a request to close a
channel by sending an err response.
Session.receiveCloseChannel() doesn't leave this
possibility open -- it tells the appropriate
StartChannelListener that it's being shutdown, then
always sets channel state to STATE_CLOSING and sends an
<ok /> response. There should either be an extension
to StartChannelListener.closeChannel() to return an
identifier marking success or failure, or a special
handling of CloseChannelExceptions around the call to
allow for sending an err response explaining the reason
for denying the channel close. If you have a preferred
fix, let me know and I'll implement it and submit a
patch.

Dave

TuningProfile.setNextProfileRegistry

Dave Golombek — Wed, 02 May 2001 03:33:38 -0000

There are many situations in which a BEEP peer may not
wish to advertise a set of profiles until after a
certain level of Authentication/Authorization has been
performed. Right now, there is no clean way to change
the ProfileRegistry as soon as a TuningProfile
successfully completes. Right now
TuningProfile.complete takes a a ProfileRegistry to
install for the newly negotiated Session, which
essentially is the same ProfileRegistry as was
installed for the last Session (TLSProfile removes
itself, but it's essentially the same). It would be
nice to have something like:

class TuningProfile .... {
private ProfileRegistry nextRegistry;

public void
TuningProfile.setNextProfileRegistry(ProfileRegistry
registry) {
nextRegistry = registry;
}

public void complete(Channel channel,
SessionCredential localCred,
SessionCredential peerCred,
Object argument) ... {
...
Session s = channel.getSession();
s.reset(localCred, peerCred, nextRegistry,
argument);
....
}
}

If I'm missing a clean way of doing this under the
current design, please let
me know. Thanks,

Dave