beepcore-ruby-discuss Mailing List for Ruby BEEP Core
Status: Planning
Brought to you by:
dmoniz
Menu
▾
▴
beepcore-ruby-discuss — Mailing list for general discussion about beepcore-ruby
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dan M. <dn...@po...> - 2004-01-20 20:15:57
|
On Monday, January 12, 2004 1:21 PM +0200 Torsten Rueger <tor...@hi...> wrote: > Moi Dan, Hi Torsten, > i'd like to use beep in my ruby powered system. Any code to be had ? > Or other info ? No real world code as of yet. The project has languished despite many attempts to kickstart it into action, mostly because I've been busy with "real life" and have had no time to hack on it and organize people. There are, however, a few folks who are (maybe) still on the SourceForge lists who would be interested in restarting it (yet again!) and moving to RubyForge. I'm still interested, of course, and still do hack Ruby and BEEP every now and then, still trying to carve out more time to do dedicated work on beepcore-ruby. > Rubyforge has opened it's gates, maybe everyone with latent interest > could wander over there and start afresh. > I'm in the fortunate position of being paid to do this, so there's a > chance to get something started. I've CC'd this to the relevant beepcore-ruby list and I'll let you know if there's any response. I'll also (I hate making these promises over and over and not delivering) try to get some substantive code up in the next couple (2! I mean it!) weeks. Thanks for your support. -- Dan Moniz <dn...@po...> [http://www.pobox.com/~dnm/] |
|
From: Nathan D. <cu...@us...> - 2003-08-04 19:21:03
|
Hi Dan Dan Moniz wrote: > Thanks for adding your code in Nathan. > >If you could, try to see if you can rearrange the layout. I notice that >currently, the code is checked in under the following CVS tree: > >beepcore-ruby/beepcore-ruby/src/prototype/curne/src > >I'd like if we kept to: > >beepcore-ruby/prototype/curne/src > >Or something similar and less confusing. > >Thanks for your support. > I think if you check that you will the source layout is as you expect. The beepcore-ruby/beepcore-ruby is a cosmetic detail of the CVSview page. If you do a cvs co beepcore-ruby the source comes out with the following structure: beepcore-ruby beepcore-ruby/src beepcore-ruby/src/prototype beepcore-ruby/src/prototype/curne beepcore-ruby/src/prototype/curne/src -- /BEEP - Adding another layer to the OSI model/ http://sourceforge.net/projects/beepcore-ruby/ |
|
From: Nathan D. <cu...@us...> - 2003-08-04 19:21:01
|
Hi List, Sorry it's taken a few days to reply but I am kind of tied down at work these days. Anyway, comments below... Dan Moniz wrote: > > >>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. > I expect the later abstraction of the transport mechanism is not a horrendous job if it becomes relevant at all. I certainly accept the vote, that TCP will be the main use for now. However, if (read: when) BEEP reaches industry standard level, I imagine it on top of SCTP. >>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. > > Well, in my experience, the simplest thing when designing an application with multiple connections (in this case, multiple channels aswell) is to just to start a thread for each and mutex of the critical regions. However, this unfailingly turns into a heap of threads sitting around doing nothing most of the time. Making a solution that supports both a threaded and non-threaded mode allows the developer to employ synchronous and asynchronous channels, both of which are relevant use cases. I do, however agree that the main goal of this project is to get it working as soon as possible. I view development-oriented discussion as something parallel to coding. I have seen too many projects go belly up from endless design discussions. As a general rule, something that works is worth more than something that looks good on paper. >>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. > > This sounds fantastic. That was exactly the type of thing I had in mind. Michael, I can see you are also a member of that group. Can you comment on the progress of the code and/or specs coming out of that project? >>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. ;] > > Yes, isn't it great :-) I agree with your general point, start small, grow big. Let's get this cool project going! Curne -- /BEEP - Adding another layer to the OSI model/ http://sourceforge.net/projects/beepcore-ruby/ |
|
From: Dan M. <dn...@po...> - 2003-07-30 09:42:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 05:38 AM 5/27/2003 +0200, Nathan Droft wrote: >I have put my own code scribbles in CVS under >beepcore-ruby/src/prototype/curne/src. I suggest that others that have >code put their's in beepcore-ruby/src/prototype/<username>/src so we can >compare notes. My own code is not worth much, its mostly a gesture :-) Thanks for adding your code in Nathan. If you could, try to see if you can rearrange the layout. I notice that currently, the code is checked in under the following CVS tree: beepcore-ruby/beepcore-ruby/src/prototype/curne/src I'd like if we kept to: beepcore-ruby/prototype/curne/src Or something similar and less confusing. Thanks for your support. - -- 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/AwUBPyeS7lmE1hyKYjtREQK+AACgnS6TJUcOW33ld4JeyCNHQMXH1rYAoIH/ 7b28JTOTFD+5cXRbJmFAcl1I =4h7o -----END PGP SIGNATURE----- |
|
From: Dan M. <dn...@po...> - 2003-07-30 09:38:06
|
-----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----- |
|
From: Nathan D. <cu...@us...> - 2003-07-04 15:20:28
|
Just to say, I am going away on vacation for two weeks and will not be reading mail from the list. See you for more BEEPing fun then. :-) Curne -- /BEEP - Adding another layer to the OSI model/ http://sourceforge.net/projects/beepcore-ruby/ |
|
From: Nathan D. <cu...@us...> - 2003-05-27 04:27:42
|
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/
|
|
From: Nathan D. <cu...@us...> - 2003-05-27 03:39:31
|
Dan Moniz wrote: > What really needs to be done is to release some code, so people can > start seeing some progress. This is my fault. I tried to drum up some > discussion on the project lists I created through SourceForge back in > September, but that hasn't happened yet. I know Michael is waiting for > code and may be progressing along with his own BEEP implementation in > Ruby for his MUD project. I would very much like to merge those > efforts, which he and I have talked about a lot before, but I stall > out and lose touch with him. I am in a similar situation where I would like to have a BEEP lib for my own projects. I started some code also, though its just a skeleton of an implementation. I think maybe a good first step would be to get all the code that different people have made out there. I have put my own code scribbles in CVS under beepcore-ruby/src/prototype/curne/src. I suggest that others that have code put their's in beepcore-ruby/src/prototype/<username>/src so we can compare notes. My own code is not worth much, its mostly a gesture :-) > If you're still interested, I can still use the help, mostly to keep > myself motivated. Subscribe to the lists and pepper me with questions. > I'll re-re-re-re-dust off the draft functional spec doc and update it > to actually say something worthwhile and would love to send that > around to the lists for comments. I hope I speak for all of us, certainly for myself, when I say that we signed up for this project because it is worthwhile doing. Personally I have great interest in seeing a functional BEEP implementation for Ruby. > And bring your friends! :-) > Thanks for your support. Not to mention it. Ruby BEEP Core is a collective effort right? Curne -- |
|
From: Dan M. <dn...@po...> - 2003-05-27 02:44:26
|
At 10:29 AM 5/14/2003 -0700, Nathan Droft wrote: >Hi Dan, Hi Nathan, >It has been a while since I signed up for the beepcore-ruby >project. I still want to contribute. Is anything happening? > >Let me know where things are. Well, more or less were they were when I last tried to jump start this. What really needs to be done is to release some code, so people can start seeing some progress. This is my fault. I tried to drum up some discussion on the project lists I created through SourceForge back in September, but that hasn't happened yet. I know Michael is waiting for code and may be progressing along with his own BEEP implementation in Ruby for his MUD project. I would very much like to merge those efforts, which he and I have talked about a lot before, but I stall out and lose touch with him. If you're still interested, I can still use the help, mostly to keep myself motivated. Subscribe to the lists and pepper me with questions. I'll re-re-re-re-dust off the draft functional spec doc and update it to actually say something worthwhile and would love to send that around to the lists for comments. And bring your friends! Thanks for your support. -- Dan Moniz <dn...@po...> [http://www.pobox.com/~dnm/] |
|
From: Dan M. <dn...@po...> - 2002-09-28 09:47:51
|
Hi all,
Despite being officially formed in Summer 2001, and after numerous false
starts, the project to implement the BEEP core (RFC 3080 and RFC 3081) in
the Ruby programming language ("Ruby BEEP Core", or colloquially
"beepcore-ruby") is now underway. We're going after the same goal as both
the Java, Tcl, and C implementations -- a full, useable core in 100% Ruby.
It's still early days yet, and we're just now discussing the overall
design, direction, and shape the project and the code is going to take, so
now is a great time to get involved.
Interested parties should check out <http://beepcore-ruby.sf.net/> and
<http://sf.net/projects/beepcore-ruby> for more information, and to sign up
on the project mailing lists.
Cheers!
--
Dan Moniz <dn...@po...> [http://www.pobox.com/~dnm/]
|
|
From: Dan M. <dn...@po...> - 2002-09-28 09:32:19
|
In a previous mail to the list that I didn't see because I wasn't subscribed (oops!), Jim Greer wrote: >Any thoughts on an class/object model of the implementation? >The beepy work (Python implementation) looks like a good start. Is beepy the same thing as PyBEEP <http://pybeep.sourceforge.net/>? Gabe Wachob, the chief designer and instigator of PyBEEP is a friend of mine, and I've talked to him about various similarities. At the moment, I don't think PyBEEP is far enough along to look at as a potential anatomical BEEP core model, but I'll ask Gabe and get the straight dope. I'm more interested in looking initially at beepcore-java because it's the BEEP core implementation that's had the most development done on it, and Huston Franklin is quick to fix bugs and explain complicated parts of the code. Gabe and I were recently writing a chapter on using BEEP to build peer-to-peer apps for a book project (which was unfortunately scrapped recently), and we selected beepcore-java because of the overall clarity, Huston's involvement and response time, and familiarity. beepcore-tcl is potentially interesting because it attacks things from a realm which is a bit close to Ruby's domain: the scripting language approach. beepcore-tcl hasn't changed much from it's original inception as one of the original implementations of BEEP's predecessor, BXXP, but it may be worth looking at to learn from, especially in the case of how it leverages other libraries and code packages in Tcl to do things like XML parsing and what not. I certainly plan to use well-accepted and robust third party Ruby code to handle some of the more basic and/or esoteric things that aren't primarily related to the internals of BEEP wherever possible. -- Dan Moniz <dn...@po...> [http://www.pobox.com/~dnm/] |
|
From: Dan M. <dn...@po...> - 2002-09-28 09:22:06
|
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/]
|
|
From: Jim G. <jg...@mi...> - 2002-09-24 23:58:24
|
Any thoughts on an class/object model of the implementation? The beepy work (Python implementation) looks like a good start. Jim G -- Do something unusual today. Pay a bill. Jim Greer (Jim <G>) <jg...@mi...> [expires: 2002-12-09] 5CE1 6822 5E85 38D5 0C5C 8FA8 9499 8A2C 3E8B A74F |
|
From: Jim G. <jg...@mi...> - 2002-09-14 14:51:09
|
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)
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)
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?
Q4) Has anyone got a driver project that we can use to tout our
implementation?
Q5) Any ideas on timeline/goals?
Jim G
--
In a museum in Havana, there are two skulls of Christopher Columbus,
"one when he was a boy and one when he was a man."
-- Mark Twain
Jim Greer (Jim <G>) <jg...@mi...> [expires: 2002-12-09]
5CE1 6822 5E85 38D5 0C5C 8FA8 9499 8A2C 3E8B A74F
|