Re: [beepcore-ruby-discuss] My thoughts on implementation

[Dan M. <dn...@po...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 06:26 AM 5/27/2003 +0200, Nathan Droft wrote:

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

Thanks for your notes Nathan. Sorry it's taken so long for me to get back 
to you on this.

[snip]

>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.

This may be something to look into in a future release; that is, beyond the
first released reference implementation of a Ruby BEEP Core. I'm 
comfortable on top of TCP for now, and while I would in general prefer 
cleanly separated code, this is an area I don't think I'd be likely to 
spend a great deal of time abstracting out should it prove to be difficult 
to do so.

>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?

I can see concurrency and Ruby threads being tar pits of complexity early 
on, so my inclination is to "do the simplest thing that could possibly 
work" in the short term to get the proof-of-concept code out, and then the 
reference implementation, and then work on making beepcore-ruby more robust
for real world use. I have a massive problem with getting code out early 
and often, so changing that behavior is my main goal.

>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.

Gabe Wachob, who started the PyBEEP project a while back, created 
BEEPBuilders <http://beepbuiders.sf.net/> as an interop and conformance 
testing group/project. I think we should get involved in that and push 
other implementers to do likewise. It sounds odd for this project which has
a pretty shoddy track record so far of keeping up on it's goals to spur 
another to the same, but it can't possibly hurt.

>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?

APEX is not part of the BEEPcore, but is something I'm interested in. 
Eventually, I'd like beepcore-ruby to be able to support any use of BEEP, 
including APEX, as well as HSTP, reliable syslog, etc. We have lots of work
to do. ;]


- -- 
Dan Moniz <dn...@po...> [http://www.pobox.com/~dnm/]

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
Comment: Please see <http://www.pobox.com/~dnm/keys.html>

iQA/AwUBPyeR9VmE1hyKYjtREQLGygCfYnyVKgNQ7RM+wDm6zZrSD3UqphUAoKYz
kKK8ZmC5uox+DCCIRDnmRB3q
=EHU/
-----END PGP SIGNATURE-----