In a previous mail to the list that I didn't see because I wasn't
subscribed (oops!), Jim Greer wrote:
>Greetings, all. I'm Jim Greer, a fellow Ruby enthusiast who is interested
>in BEEP, though I can't claim significant work using either. I am
>interesting in contributing to this project. I have a few questions, though:
>
>Q1) What is this project?
>
>That is, what is the scope of the intended work?
>
>A reference implementation of BEEP in Ruby? (correct)
>The definitive core implementation of BEEP in Ruby? (correct & good)
>A complete BEEP implementation in Ruby? (complete)
I started the project originally with the intent to provide an
implementation of the "BEEP core" as defined in RFC 3080 and RFC 3081 in
Ruby. This fulfills the second description and the third description, as
long as you don't include things like APEX and Reliable Syslog, which are
built with BEEP (on top of BEEP) in the idea of a "complete BEEP
implementation".
Having said that, once the core is done, APEX and friends are definitely
things I want to work with. The core needs to be there first, however, for
everything else to work.
>Q2) How will this project differ from other BEEP implemetations?
>
>By language of implementation only? (Ruby)
>By reflection of language idiom(s) for more natural expression of the
>problem? (Rubyifed BEEP)
I think it'll differ in both the ways mentioned, starting out with the
first criteria as it's most obvious and hard to escape. Over time, the
second criteria will naturally be met if we do a good job -- a BEEP core in
Ruby that reads like Tcl or Java wouldn't be very good Ruby.
There will likely be some growing pains as each of transitions from what we
know to Ruby, so I don't expect code to be perfect idiomatic Ruby for quite
a while, instead, we'll evolve towards it as we get a better sense of BEEP
and the mapping to Ruby as a language. Until then, I fully expect to crib
from other existing BEEP core implementations to use as a skeleton.
>Q3) Have any of you thoughts about your initial and long-term design and
>implementation strategies?
>
>{ natural implications from above }
>Candidate objects, anyone?
>
>Use SWIG + reference C-BEEP, concentrating on integration level work?
>Use SWIG + custom C-BEEP?
>'Native' BEEP implementation?
If I understand your question correctly, I'm going after a native
implementation in 100% pure Ruby. Again, I expect to do a lot of hard
looking at other BEEP core implementations (namely beepcore-java and
potentially beepcore-tcl) and copying the general layout where it makes
sense to do so, to give the project a starting point.
>Q4) Has anyone got a driver project that we can use to tout our
>implementation?
Well, I _did_, when I originally started this. I had planned to build
beepcore-ruby out in the open and use it internally at the company I was
working for at the time to prototype a lot of ideas we had kicking about.
We were in the peer-to-peer network and application space, and I really
thought we should be using BEEP and APEX at the time, rather than crafting
our own ad hoc protocols.
Michael wants to use BEEP to power MUES, a MUD he's building. Michael, can
you talk about that in some detail?
>Q5) Any ideas on timeline/goals?
As it is, I'm way past all my original idyllic deadlines, but that's okay.
I've also been dragging my feet since Michael first contacted me and got me
rolling on this again, but thanks to increasing interest, such as from
people like you, I'm more motivated than ever. I'm trying very hard to make
beepcore-ruby my primary free-time hacking project. We'll see how it goes.
As for general immediate milestones, I promised Michael a rough design doc
months ago and still haven't gotten that out. After that, it's time to
build the scaffolding that'll follow the design and allow us to start
writing code. I expect and hope for a lot of discussion at this stage so
that we can get everyone's thoughts in.
Thanks for your questions!
--
Dan Moniz <dn...@po...> [http://www.pobox.com/~dnm/]
|
