beepcore-java-users — Discussion list for developers using beepcore-java library

RE: [Beepcore-java-users] Waiting for a message in a client appli cation

[Serge A. <sA...@in...>]

Thank you; I have understood that now.
Is there any document describing the threading model implemented by the API?
I had to look in the sources to understand when a listening thread is
started.

-- Serge

-----Original Message-----
From: Huston [mailto:hu...@us...] 
Sent: Thursday, August 29, 2002 17:06
To: Serge Adda; Bee...@li...
Subject: Re: [Beepcore-java-users] Waiting for a message in a client
application

All you should have to do is start a channel with a MessageListener and the
MessageListener will be called when a MSG is received.

--Huston

----- Original Message -----
I have started a session in a client application.
Then I would like to set up a channel in order to wait for incoming messages
from the server application.

Re: [Beepcore-java-users] Waiting for a message in a client application

[Huston <hu...@us...>]

All you should have to do is start a channel with a MessageListener and the
MessageListener will be called when a MSG is received.

--Huston

----- Original Message -----
I have started a session in a client application.
Then I would like to set up a channel in order to wait for incoming messages
from the server application.

[Beepcore-java-users] Waiting for a message in a client application

[Serge A. <sA...@in...>]

Hello,

I have started a session in a client application.

Then I would like to set up a channel in order to wait for incoming messages
from the server application.

 

Could anybody explain how to perform these operations?

 

Thanks,

 

Serge 

Re: [Beepcore-java-users] sendMSG depricated

[Huston <hu...@us...>]

> The sendMSG method in SharedChannel is deprecated even though the
> sendMSG method in Channel is not.  Is this correct?
>
> Should I be using something else besides sendMSG anyway?  Should I be
> using the sendRequest method of SharedChannel?

I think the original developer did that because he wanted to encourage the
use of sendRequest. sendMSG is fine to use so I will remove the deprecated
tag.

Thanks,
--Huston

Re: [Beepcore-java-users] Implenting LogService using java.util.logging in j2se

[Huston <hu...@us...>]

> Hi,
> 
> The following code is an implementation of the beepcore-java LogService
> interface using the new logging package provided by the JDK 1.4.0.
> The beep2j2se is a tentative to convert severity to level.
> 
> Serge

Thanks! If it is ok with you I would like to add it to cvs.

--Huston

[Beepcore-java-users] Implenting LogService using java.util.logging in j2se

[Serge A. <sA...@in...>]

Hi,

The following code is an implementation of the beepcore-java LogService
interface using the new logging package provided by the JDK 1.4.0.
The beep2j2se is a tentative to convert severity to level.

Serge
----------------------------------------------------------------------------
------------------------

/*
 * BeepLogger.java
 *
 * Created on August 28, 2002, 5:59 PM
 */

import org.beepcore.beep.util.*;

import java.util.logging.*;

/**
 *
 * @author  sad
 */
public class BeepLogger implements LogService {
    
    private Logger logger_;
    
    /** Creates a new instance of BeepLogger */
    public BeepLogger() {
        this(Log.SEV_ERROR);
    }
    
    /** Creates a new instance of BeepLogger */
    public BeepLogger(int severity) {
        this(Logger.global, severity);
    }
    
    /** Creates a new instance of BeepLogger */
    public BeepLogger(Logger logger, int severity) {
        logger_ = logger;
        setSeverity(severity);
    }
    
    private Level beep2j2se(int sev) {
        switch (sev) {
            case Log.SEV_EMERGENCY:
            case Log.SEV_ALERT:
            case Log.SEV_CRITICAL:
            case Log.SEV_ERROR:
                return Level.SEVERE;
            case Log.SEV_WARNING:
                return Level.WARNING;
            case Log.SEV_NOTICE:
            case Log.SEV_INFORMATIONAL:
                return Level.INFO;
            case Log.SEV_DEBUG:
                return Level.FINE;
            case Log.SEV_DEBUG_VERBOSE:
                return Level.ALL;
            default:
                return Level.ALL;
        }
    }
    
    /** Used to determine if a message of <code>sev</code> will be logged.
     *
     */
    public boolean isLogged(int sev) {
        return logger_.isLoggable(beep2j2se(sev));
    }
    
    /** Used decide if a message of <code>sev</code> will be logged.
     *
     */
    public void setSeverity(int sev) {
        logger_.setLevel(beep2j2se(sev));
    }
    
    /** Method logEntry
     *
     *
     * @param sev
     * @param service
     * @param message
     *
     *
     */
    public void logEntry(int sev, String service, String message) {
        logger_.log(beep2j2se(sev), service + ": " + message);
    }
    
    /** Method logEntry
     *
     *
     * @param sev
     * @param service
     * @param exception
     *
     *
     */
    public void logEntry(int sev, String service, Throwable exception) {
        logger_.log(beep2j2se(sev), service,  exception);
    }
}

[Beepcore-java-users] sendMSG depricated

[Andrew N. <an...@ec...>]

The sendMSG method in SharedChannel is deprecated even though the 
sendMSG method in Channel is not.  Is this correct?

Should I be using something else besides sendMSG anyway?  Should I be 
using the sendRequest method of SharedChannel?

-andy

Re: [Beepcore-java-users] SharedChannel ?

[Huston <hu...@us...>]

Sorry, I broke that with my check-in last night. I'll fix it tonight.

--Huston

----- Original Message ----- 
From: "Harsh Daharwal" <hda...@io...>
To: <bee...@li...>
Sent: Wednesday, August 21, 2002 4:21 PM
Subject: [Beepcore-java-users] SharedChannel ?


> 
> .../org/beepcore/beep/lib/SharedChannel.java (v1.5)
> 
> The ctor of this class calls its super (Channel) with 4 arguments. I
> could not find any such Channel ctor in
> .../org/beepcore/beep/core/Channel.java (v1.25)
> 
> 
> Harsh Daharwal
> (972)424-6931
> 
> 

[Beepcore-java-users] SharedChannel ?

[Harsh D. <hda...@io...>]

.../org/beepcore/beep/lib/SharedChannel.java (v1.5)

The ctor of this class calls its super (Channel) with 4 arguments. I
could not find any such Channel ctor in
.../org/beepcore/beep/core/Channel.java (v1.25)


Harsh Daharwal
(972)424-6931

Re: [Beepcore-java-users] some questions about BEEP

[Huston <hu...@us...>]

Message> 1. Can the BEEP client start the channel listener?

yes, all you need to do is add the profile to the ProfileRegistry on the
initiator and the listener should be able to start a channel.

--Huston

Re: [Beepcore-java-users] some questions about BEEP

[William J. M. <wm...@ol...>]

Well, I might punt to Huston, but it *should* work.  It looks to me like you
are doing the right thing.

Once the session is set up, it's peer to peer, so anything you register/advertise
in your greeting the other end is supposed to be able to send a start for.

-bill


On Thu, Aug 15, 2002 at 05:03:10PM -0700, Russell Hung wrote:
> Hi, 
>  
> Two questions:
>  
> 1. Can the BEEP client start the channel listener? 
>     After the client register a channel listener, the client would have
> a connection with it's server using:
>         Session session = AutomatedTCPSessionCreator.init(host,
> listenPort, profileRegistry);
>    
> 2. Can the "session" on the BEEP server initiate a channel when the
> client has a channel listener?
>         Session session = AutomatedTCPSessionCreator.listen(listenPort,
> profileRegistry);
>     then, use the session returned from "listen":
>         Channel channel = session.startChannel(EchoProfile.Echo_URI);
>  
> I didn't see any BEEP examples did that, and I cannot make it work. 
>  
> Thanks for your help,  
>  
> Russell Hung
> rh...@vi...
> 

Re: [Beepcore-java-users] building a channel listener on client and open a channel on server side

[William J. M. <wm...@ol...>]

Russel,

Sounds like you are having some luck, cool!

You need to register the prfile in the "client" or connecting peer, and 
it needs to be registered as a listener.  If you are watching the connection
with ethereal (a sniffer) or testing the "client" it needs to have a 
populated <greeting> instead of just an empty <greeting></greeting>.

The code in the connecting peer will look a lot like the server code.

Does this help?

-bill

On Thu, Aug 15, 2002 at 10:10:52AM -0700, Russell Hung wrote:
> Hi,
>  
> I am trying to build a channel from server to client (server ---->
> client) so the server could send the messages actively. 
>  
> I have successfully built a channel from client to server (client ---->
> server) using - 
> on server side: 
>  
>     startChannelListener = profile.init(uri, profileConfiguration);
>     profileRegistry.addStartChannelListener(uri, startChannelListener,
> sessionTuningProperties);
>  
> and client side:
>  
>     // builds a session using "AutomatedTCPSessionCreator.initiate(...)"
> 
>     channel = session.startChannel(EchoProfile.EchoProfile_URI);
>  
> After that (there is already a channel "client ---> server"), I try to
> build a channel from server to client ("server -----> client") so the
> server could actively send messages to client using the same algorithm -
> on client side:
>  
>     startChannelListener = profile.init(uri, profileConfiguration);
>     profileRegistry.addStartChannelListener(uri, startChannelListener,
> sessionTuningProperties);
>  
> and server side:
>  
>     // after the server agree with client's session request, it obtains
> a session. 
>     session = AutomatedTCPSessionCreator.listen(listenPort,
> profileRegistry);    
>     channel = session.startChannel(EchoProfile.EchoProfile_URI);
>  
> It returns the error messages below after the server side tries to start
> a channel:
>  
>     "org.beepcore.beep.core.BEEPError: all requested profiles are
> unsupported"
>  
> Is building a channel from server to client feasible? Or maybe I did
> something wrong!  Thanks.
>  
>  
> Russell Hung
> rh...@vi...
> 

Re: [Beepcore-java-users] Newbie questions

[Harsh D. <hda...@io...>]

If I may add to that:
- Who are known commercial/non-commercial users of it?

Wolfgang Hoschek said:
> I'm new to beepcore and have a few questions:
>
> - What are the main differences between beepcore and other java based
> beeps? - What is the concurrency model? one thread per message? NIO IO?
> - Are there any known issues & problems?
> - What will be the delta between the current and the next release? -
> What is a good guess for the next release date?
> - Are there any benchmarks around, or at least experiences?
> - How stable is it in your experience?
>
> Thanks,
> Wolfgang.
>
> -------------------------------------------------------------------------
-----
> Wolfgang Hoschek, CERN IT Division, European Organization for Nuclear
> Research Wol...@ce..., http://cern.ch/hoschek, phone:  +41
> (22) 767 8089
> -------------------------------------------------------------------------
-----
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-java-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-java-users


Harsh Daharwal
(972)424-6931

[Beepcore-java-users] Newbie questions

[Wolfgang H. <wol...@ce...>]

I'm new to beepcore and have a few questions:

- What are the main differences between beepcore and other java based beeps?
- What is the concurrency model? one thread per message? NIO IO?
- Are there any known issues & problems?
- What will be the delta between the current and the next release?
- What is a good guess for the next release date?
- Are there any benchmarks around, or at least experiences?
- How stable is it in your experience?

Thanks,
Wolfgang.

------------------------------------------------------------------------------
Wolfgang Hoschek, CERN IT Division, European Organization for Nuclear Research
Wol...@ce..., http://cern.ch/hoschek, phone:  +41 (22) 767 8089
------------------------------------------------------------------------------

Re: [Beepcore-java-users] Re: Beepcore-java-users digest, Vol 1 #76- 8 msgs

[Kevin K. <kk...@my...>]

On Tue, 2002-08-06 at 16:55, Darren New wrote:
> Kevin Kress wrote:
> > I am more interested in situations where the profile already exists and
> > the application designer wishes to layer security/authentication under
> > it.  This would allow the security layer to exist without the profile
> > having to expressly know the security is there.
>=20
> Right. This can already be done for TLS. Otherwise, you're saying everyon=
e
> with credentials on the server can run all the operations via this profil=
e
> identically. I don't think that's actually going to be too common.
>=20
> Putting a call in the start routine that says "is my configuration flag s=
et?
> If so, is the user name non-empty? If so, go ahead" makes sense. The prof=
ile
> is still going to have to generate a profile-specific message denying
> permission to open the channel.

So I guess it does make more sense to have a full set of utilities to
allow a profile to get as much information about the credentials and
encryption available (or active) in a session and then leave the rest up
to the profile.

.... OK I have another question that this discussion has raised.  When
exactly does a TuningProfile warrent a session reset and resending of
greetings?  Does it corresond only with the encoding change, in the
example of TLS?  Can any TuningProfile mandate a greeting exchange after
establishment as long as that is specified in the specification of the
profile?

Thanks,

--Kevin

Re: [Beepcore-java-users] profile unsuported exceptioin

[William J. M. <wm...@ol...>]

If you telnet to the server code are you getting a greeting with the 
ECHO profile in it?


On Wed, Aug 07, 2002 at 02:50:57PM -0700, Russell Hung wrote:
> Hi, 
>  
> I have a "org.beepcore.beep.core.BEEPError: all requested profiles are
> unsupported" exception returned on the client side. 
>  
> On server side:
>   
>     startChannelListener = echoProfile.init(echoProfile.ECHO_URI, new
> ProfileConfiguratioin());
>     profileRegistry.addStartChannelListener(echoProfile.ECHO_URI,
> startChannelListener, sessionTuningProperties)
>     session = AutomatedTCPSessionCreator.listen(listenPort, proReg);
>  
> On client side:
>  
>     session = AutomatedTCPSessionCreator.initiate(host, port, new
> ProfileRegistry());
>     channel = session.startChannel(EchoProfile.ECHO_URI);
>     // the above exception is threw there. 
>  
> Did I do anything wrong? Thanks. 
>  
> Russell Hung
> rh...@vi...
>  
> 

Re: [Beepcore-java-users] Re: Beepcore-java-users digest, Vol 1 #76- 8 msgs

[Darren N. <dn...@sa...>]

Kevin Kress wrote:
> I am more interested in situations where the profile already exists and
> the application designer wishes to layer security/authentication under
> it.  This would allow the security layer to exist without the profile
> having to expressly know the security is there.

Right. This can already be done for TLS. Otherwise, you're saying everyone
with credentials on the server can run all the operations via this profile
identically. I don't think that's actually going to be too common.

Putting a call in the start routine that says "is my configuration flag set?
If so, is the user name non-empty? If so, go ahead" makes sense. The profile
is still going to have to generate a profile-specific message denying
permission to open the channel.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

They looked up at me like I was a T-bone steak
  walking into an all-you-can-eat seafood buffet.

Re: [Beepcore-java-users] Re: Beepcore-java-users digest, Vol 1 #76 - 8 msgs

[Kevin K. <kk...@my...>]

Ok so maybe SMTP was not the best example for this, in the case I would
propose that the SMTP profile contacts the session and asks for the
session's credentials, which should include the username and password.

But with your example you are writing a requirement that explicitly
requires the profile to interact with the authentication system.

I am more interested in situations where the profile already exists and
the application designer wishes to layer security/authentication under
it.  This would allow the security layer to exist without the profile
having to expressly know the security is there.

--KMK

On Tue, 2002-08-06 at 16:18, Darren New wrote:
> > > If this were setup at the session layer, the profile would be blissfully
> > > unaware of what is running underneath it (unless that info is
> > > specifically requested form the session).  It would be the job of the
> > > session to determine whether a profile has enough
> > > authentication/encryption/etc in place.  How would it determine this?
> 
> The problem comes when you add the requirement
>   SMTP checks that the "From:" address belongs to the user 
>   who logged in via SASL.
> 
> All of a sudden, you're back to having SMTP no longer blissfully unaware of
> SASL any more.
> 
> -- 
> Darren New 
> San Diego, CA, USA (PST). Cryptokeys on demand.
>    ** http://images.fbrtech.com/dnew/ **
> 
> They looked up at me like I was a T-bone steak
>   walking into an all-you-can-eat seafood buffet.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-java-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-java-users
> 
-- 
Kevin Kress
kk...@my...

GnuPG Key ID: 92949032
Fingerprint : B7F9 2B08 6FC8 35CA 5B64  BD34 6A8B 325C 9294 9032

See Keyserver: http://www.keyserver.net/en/findkey.html
(search for "Kevin Kress" or "0x92949032")

Get GnuPG or PGP at http://www.pgpi.org

[Beepcore-java-users] Re: Beepcore-java-users digest, Vol 1 #76 - 8 msgs

[Darren N. <dn...@sa...>]

> > If this were setup at the session layer, the profile would be blissfully
> > unaware of what is running underneath it (unless that info is
> > specifically requested form the session).  It would be the job of the
> > session to determine whether a profile has enough
> > authentication/encryption/etc in place.  How would it determine this?

The problem comes when you add the requirement
  SMTP checks that the "From:" address belongs to the user 
  who logged in via SASL.

All of a sudden, you're back to having SMTP no longer blissfully unaware of
SASL any more.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

They looked up at me like I was a T-bone steak
  walking into an all-you-can-eat seafood buffet.

Re: [Beepcore-java-users] About BEEP output and input stream

[Huston <hu...@us...>]

> It uses the message reply object to get the input stream. That
> means we have to send a message and
> wait for the response. This is not what I want. What I need are two
> independent threads: one for
> listening to the port/messages and one for sending out the message through
> the port. Is there any way to
> have an independent InputStream? Thanks.

You should be able to do what you want by providing your own implementation
of the ReplyListener interface. The Reply class is just a simple
implementation of this interface for people who prefer to deal with things
in a synchronous manner.

--Huston

Re: [Beepcore-java-users] Requireing a profile

[Huston <hu...@us...>]

> All,
>
> I just wanted to point out that I am a newcomer to beep, and I am coming
> to this after reading the RFC only 2 or 3 times, so I want to admit up
> front I could be completely off base, but I figured I may as well try to
> explore the idea.  Also if I am just rehashing something that has
> already been discussed please let me know.
>
> Throwing the responsibility of check dependencies to the parent class of
> the TuningProfile is more along the lines of what I had in mind, but let
> me put up and example that is a little more along the lines of what I
> had in mind.
>
> This not in any way a real world example, but something I have come up
> with to further discussion.
>
> for this example there exists 5 profiles (full URI's removed for
> brevity)
>
> - TLS
> - SASL/ANONYMOUS
> - SASL/OTP
> - SASL/OTHER (one that negotiates both authentication and a security
> layer)
> - Some Application profile, lets say SMTP.
>
>
> Now consider the following situations all implemented in different
> software processes:
>
> case 1:
> SMTP requires SASL/OTP
> SASL/OTP requires TLS
>
> case 2:
> SMTP requires SASL/ANONYMOUS
>
> case 3:
> SMTP requires SASL/OTHER
>
> case 4:
> SMTP requires nothing.
>
> In each of these cases SMTP works exactly the same once the channel is
> started, ie no change in functionality.  What I am proposing is that the
> core functionality be written so that it can be aware of these different
> dependencies and handle them, so the application writer does not have to
> worry about them at a profile level, only at the session level.
>
> Now in the case where the profile is aware of the authentication layers
> that are sitting above it, the SMTP Profile (or its parent class) has to
> check to see what encryption/authentication schemes are in place and
> compare those to what it knows about.  This would require the session to
> call to he profile and then the profile to veto the start channel until
> proper authentication is in place.
>
> If this were setup at the session layer, the profile would be blissfully
> unaware of what is running underneath it (unless that info is
> specifically requested form the session).  It would be the job of the
> session to determine whether a profile has enough
> authentication/encryption/etc in place.  How would it determine this?
> The ProfileRegistry could be augmented to contain a dependency scheme.
> This could allow for both tuning and application profile dependencies.
> Say for a certain application you want to combine Echo profile with SMTP
> (don't ask me why just an example), but that you do not want Echo to be
> able to start unless a SMTP channel is already open.  Using dependencies
> you could have attempts to start Echo fail until SMTP is up.
>
> Here is where my ignorance of the details of BEEP comes in, are these
> idea valid within the bounds of the specification.  From what I
> understand for case 1 TLS should be the only protocol for the initial
> greeting and SALS/OTP and SMTP come after that, but is it also legal to
> advertise all 3 up front and have start requests to SASL/OTP and SMTP
> error out?  Also if that is that is the case then should SMTP be
> returning errorcode 530's before OTP is complete?  Should OTP be
> throwing out errorCodes if TLS has not been started (534? 538? 550?)

Yes you could return an error. I prefer not advertising the profile until
the minimum requirements that require tuning resets have been met (e.g.
encryption).

Support for this basic idea currently exist in the library between the
tuning properties in ProfileRegistry and the start channel listener code in
Session, but it could use some work. I think currently it returns 550 for
all error cases.

Another feature that was planned along this same line of thought is to also
be able to restrict starting a channel based on attributes for a given
tuning property (e.g. key length).

--Huston

Re: [Beepcore-java-users] Requireing a profile

[Marshall R. <mr...@db...>]

hi. just a quick, non-responsive reply: it's perfectly fine to ask
questions, etc., and you won't be judged on your newness to the beep stuff.

i think there are several reasonable policies and abstractions that one
could configure to provide the functionality you're interested in (and it is
useful functionality).

/mtr

Re: [Beepcore-java-users] About BEEP output and input stream

[Kevin K. <kk...@my...>]

If you do not want to wait for message to come back then you could
create a thread for sending out the messages and register your own
implementation "ReplyListener" for the sendMSG() call that could handle
the messages for you.  Not exactly sure if this is what you had in mind
though.

Not sure what you mean by "independent InputStream".

Hope that helps,

--Kevin Kress

On Tue, 2002-08-06 at 14:20, Russell Hung wrote:
> Hi,
>  
> I have a question about the input and output stream of BEEP. I read the
> example on the book, "BEEP", written by Dr. Marshall T. Rose and
> published by O'Reilly. There is a client example on page 52:
>  
> try {
>     channel.sendMSG(new StringOutputDataStream(request), reply);
> } catch { ....}
>  
> InputDataStream ds = reply.getNextReply().getDataStream();
> InputStream is = ds.getInputStream();
>  
> while(is.read() != -1) {
>     ++replyLength;
> } 
>  
> It uses the message reply object to get the input stream. That means we
> have to send a message and wait for the response. This is not what I
> want. What I need are two independent threads: one for listening to the
> port/messages and one for sending out the message through the port. Is
> there any way to have an independent InputStream? Thanks. 
>  
> Best Regards,
>  
> Russell Hung
> rh...@vi...
> 
-- 
Kevin Kress
kk...@my...

GnuPG Key ID: 92949032
Fingerprint : B7F9 2B08 6FC8 35CA 5B64  BD34 6A8B 325C 9294 9032

See Keyserver: http://www.keyserver.net/en/findkey.html
(search for "Kevin Kress" or "0x92949032")

Get GnuPG or PGP at http://www.pgpi.org

Re: [Beepcore-java-users] About BEEP output and input stream

[William J. M. <wm...@ol...>]

Can you hand off the reply object to the reply handler thread?  BEEP won't
care who deals with it.  

On Tue, Aug 06, 2002 at 02:20:53PM -0700, Russell Hung wrote:
> Hi,
>  
> I have a question about the input and output stream of BEEP. I read the
> example on the book, "BEEP", written by Dr. Marshall T. Rose and
> published by O'Reilly. There is a client example on page 52:
>  
> try {
>     channel.sendMSG(new StringOutputDataStream(request), reply);
> } catch { ....}
>  
> InputDataStream ds = reply.getNextReply().getDataStream();
> InputStream is = ds.getInputStream();
>  
> while(is.read() != -1) {
>     ++replyLength;
> } 
>  
> It uses the message reply object to get the input stream. That means we
> have to send a message and wait for the response. This is not what I
> want. What I need are two independent threads: one for listening to the
> port/messages and one for sending out the message through the port. Is
> there any way to have an independent InputStream? Thanks. 
>  
> Best Regards,
>  
> Russell Hung
> rh...@vi...
> 

Re: [Beepcore-java-users] Requireing a profile

[Kevin K. <kk...@my...>]

Resend.... Reply-to was wrong... OOPS.

see comments below....

--Kevin
-------

On Tue, 2002-08-06 at 12:38, Marshall Rose wrote:
> > A note on tuning profiles, SASL is a tuning profile that affects the
> session
> > state, but does not issue a tuning reset.
> 
> actually, this is not true. if a security layer is negotiated as a part of
> the SASL process, then a tuning reset will occur.
> 
> 
> > The design decision we made was to leave this kind of thing out, because
> it can
> > be implemented in the profiles, there did not appear to be a general
> solution,
> > and perhaps the greatest consideration was that it adds a lot of
> complexity to the
> > wrapper.
> 
> in the C and Tcl implementations, each data exchange profile is responsible
> for determining whether the tuning is to its liking or not.
> 
> in the Java implementation, one could (as bill points out), have a subclass
> of Profile that does the checking for you, so that the profile itself
> doesn't have to check. seems like a fairly straight-forward abstraction to
> put together.
> 
> however, at the present time, beepcore-java doesn't have that abstraction.
> 
> /mtr
> 

All,

I just wanted to point out that I am a newcomer to beep, and I am coming
to this after reading the RFC only 2 or 3 times, so I want to admit up
front I could be completely off base, but I figured I may as well try to
explore the idea.  Also if I am just rehashing something that has
already been discussed please let me know.

Throwing the responsibility of check dependencies to the parent class of
the TuningProfile is more along the lines of what I had in mind, but let
me put up and example that is a little more along the lines of what I
had in mind. 

This not in any way a real world example, but something I have come up
with to further discussion.  

for this example there exists 5 profiles (full URI's removed for
brevity)

- TLS
- SASL/ANONYMOUS
- SASL/OTP
- SASL/OTHER (one that negotiates both authentication and a security
layer)
- Some Application profile, lets say SMTP.


Now consider the following situations all implemented in different
software processes:

case 1:
SMTP requires SASL/OTP
SASL/OTP requires TLS

case 2:
SMTP requires SASL/ANONYMOUS

case 3:
SMTP requires SASL/OTHER

case 4:
SMTP requires nothing.

In each of these cases SMTP works exactly the same once the channel is
started, ie no change in functionality.  What I am proposing is that the
core functionality be written so that it can be aware of these different
dependencies and handle them, so the application writer does not have to
worry about them at a profile level, only at the session level.

Now in the case where the profile is aware of the authentication layers
that are sitting above it, the SMTP Profile (or its parent class) has to
check to see what encryption/authentication schemes are in place and
compare those to what it knows about.  This would require the session to
call to he profile and then the profile to veto the start channel until
proper authentication is in place.  

If this were setup at the session layer, the profile would be blissfully
unaware of what is running underneath it (unless that info is
specifically requested form the session).  It would be the job of the
session to determine whether a profile has enough
authentication/encryption/etc in place.  How would it determine this? 
The ProfileRegistry could be augmented to contain a dependency scheme. 
This could allow for both tuning and application profile dependencies. 
Say for a certain application you want to combine Echo profile with SMTP
(don't ask me why just an example), but that you do not want Echo to be
able to start unless a SMTP channel is already open.  Using dependencies
you could have attempts to start Echo fail until SMTP is up.

Here is where my ignorance of the details of BEEP comes in, are these
idea valid within the bounds of the specification.  From what I
understand for case 1 TLS should be the only protocol for the initial
greeting and SALS/OTP and SMTP come after that, but is it also legal to
advertise all 3 up front and have start requests to SASL/OTP and SMTP
error out?  Also if that is that is the case then should SMTP be
returning errorcode 530's before OTP is complete?  Should OTP be
throwing out errorCodes if TLS has not been started (534? 538? 550?)

Thanks for any comments.

--Kevin Kress