[beepcore-ruby-discuss] My thoughts on implementation

[Nathan D. <cu...@us...>]

Hi Beepers,

Just thought I would dabble out some notes, just to get the ball rolling 
again.

*Message I/O*

First off I thought that a message should contain a MessageOutput (for 
sending messages) or a MessageInput (for receiving messages). For 
instance a MessageOutput would have the following interface:

    * #write(s)
          o Send the given bytes into the message buffer (flush buffer
            and send a message segment if buffer limit reached)
          o s - some bytes of a message to send
    * #close()
          o Close the message output and send remaining bytes

Equally MessageInput would have methods #read(n) and #close(). Of course 
this idea might just stem from the fact that I code Java for my day job 
and am used to having InputStream and OutputStream. I was looking at 
extending the Ruby IO class for these classes, but it seems impossible 
to implement a clean custom version since it depends on file descriptors.

*Message Encapsulations*

Another thought I had was to apply a message encapsulation to a message 
stream, thus wrapping the data sent in a chosen format. As we all know, 
BEEP enforces no message format inside the payload, but often uses a 
simple MIME format for control messages. The few encapsulations I had in 
mind were:

    * Verbatim (default, do not add any format to the payload)
    * MIME
    * DIME (you might be going 'hmmm' here, but someone might want to
      use this)

The added value would be that the programmer would not have to parse the 
message payload just to get the headers. Rather they could use 
OutgoingMessage#set_property(name,value) and 
IncomingMessage#get_property(name) for access to these. Also the message 
format could be switched without any change in code, while retaining the 
same support for message headers.

For it all to make sense, the default message encapsulation of a channel 
should be a property of the profile.

*Transport*

Maybe this goes without saying, but I thought to mention it, just in 
case. Of course, the TCP/IP mapping will be the choice of 
implementation, but I suggest that the BEEP transport code is abstracted 
such that other transport mechanisms can be used, i.e. a different 
transport mapping can be plugged into a session.

If nobody thinks that anything other than TCP will be useful...; well, 
fair enough, but I can easilly imagine so. One of my own ideas center 
around IPC communication via BEEP and the transport being shared memory.

*Threads*

What are peoples thoughts on threading and thread utilization? 
Personally, I feel that the Ruby BEEP Core should function in both 
modes, single threaded and multi. The session should not need any 
disparate configuration, although it would be necessary to have the 
profile implementation decide whether it wants to pull messages or run 
in asynchronous mode. Thus, the (a)synchronicity of communication would 
be a by-channel property.

Also, does anyone know of any material discussing Good(tm) profile 
implementation? Seems to me, that the spec does not explicitly state, 
that profiles may not block eachother's channels in the application (the 
BEEP implementation, of course, may not) but what are the issues 
regarding deadlock? Do we have any means of supporting this for the 
developer, making it easier to avoid stupidity? Do we choose not to care?

*Interoperability*

Which implementation do we plan to use for testing against? Is there an 
approved test profile that is commonly used to test interop between 
implementations? If possible, I think it would be a good idea to have 
contact with at least one other BEEP project to communicate on the issue 
of making implementations that function with eachother.

*APEX*

Well, for now I know that we are just going to try to actually get some 
BEEP code running but what are our plans for the future? How far does 
the Ruby BEEP Core go? /The Application Exchange Core/ is a cool place 
to go when you have BEEP and maybe an APEX framework would a logical 
next step?

Well, just my thoughts so far.
Thoughts, comments?

Curne.
--
/BEEP - Adding another layer to the OSI model/
http://sourceforge.net/projects/beepcore-ruby/