Slashdot Mirror

This article points to a bunch of other efforts from the past. This list is most notably missing BEEP which also included the ability to multiplex multiple streams on top of TCP at the application layer.

I hope they're able to synthesize all of the thinking from these protocols into their work, and they bring this into the IETF and W3C for discussion when it's appropriate...

Moreover, they've written several times that SubEthaEdit leverages several OSX technologies, including both Bonjour and Cocoa, as well as makes (unorthodox?) use of open protcols like BEEP. From the sound of it, getting SEE to work without this toolkit would be very hard to do.

I'm a little more interested in support for the SEE protocol in an editor like Vim or Emacs. If they can add it, then it'll instantly be available to people using any platform at all, even if SEE never gets ported to anything else. From what I can tell, this is a lot more likely, but so far I haven't heard of anyone working on hacking up these editors to support SEE style collaborative editing. Oh well...

If Apple breaks this intentionally (meaning not for adding significant, enhanced functionality) in their next release, I will stand with you as an anti-Apple nay-saying zealot and deride them all up and down /.

-Potentially recovering Mac zealot (it's so hard with WWDC right around the corner :-( )

Take a look at this:

BEEP, the Application Protocol Framework
http://www.beepcore.org/beepcore/about_qanda.jsp

• Include it by default, or at least make it SUPER EASY to install. (It's not click-and-run like some other extensions are, because it's not pure XUL -- there's a native library involved.)
• Allow Thunderbird to handle sending and receiving of meeting invitations (I understand this is in the works)
• Schedule meetings while looking at the invitees' free/busy times. Since Thunderbird already has LDAP support, it should be trivial to look in LDAP for someone's free/busy list URL.
• Most importantly of all, it needs to support server-side calendar store! The open source community appears to want to standardize on IMAP (just a folder called "Calendar" full of vCalendar objects), and that's just a dandy way of doing it. Nobody (and I mean nobody at all) has implemented CAP because it's so damn hairy. WCAP has a small following because it's what Netscape...iPlanet...SunONE Calendar Server uses, but IMAP is still the better solution because every mail program already supports it.

Also if you install XGrid or just extract the parts from the installer package using Pacifist there's a nice little Objective-C BEEP.framework with headers and comments and everything! I think this is the first Objective-C BEEP framework on Mac OS X. It would be nice if Apple made this part of Darwin. More info here

If you're looking for something closer to real-time (a way for the server to initiate contact with the client) check out the BEEP protocol.

From the BEEP web page:
BEEP is a turbocharger for Internet applications that offers advanced features such as:

• a standard application layer that supports dynamic, pluggable application "profiles" (protocols)
• peer-to-peer, client-server, or server-to-server capabilities
• multiple channels over a single authenticated session
• support for arbitrary MIME payloads, including XML

Yes - do away with this ridiculous notion of 'ports' and turn each port into a single 'location', with the routers handling the... umm... routing. It's not as if ports have a physical existence - it's just a concept in a driver, after all. Now everyone just gets one port on one ip from their new DCHPv61 server and everything is multiplexed through that port, with BEEP or something.

Sure - it wouldn't be compatible with IPv4, but neither is IPv6! And this way is alot cheaper! And it would be completely voluntary, you could move over as necessary. And you could still make outgoing connections to IPv4 computers quite easily.

Hey that's not such a bad idea, actually.

BEEP is a "roll-your-own" protocol standard. See the BEEP web site for more details.

BEEP's an impressive protocol framework with even more impressive implementations.

I'm using it in a burgeoning open source project because of it's ability to multiplex bidirectional communication channels in a transparent fashion. Other features such as dynamic client/server roles, authentication, and channel encryption are just icing on the cake. The less I have to muck around with protocol state details the better!

When I first started looking at BEEP I was impressed by the spec but I was suspicious as to the quality and breadth of implementations. After looking through the high level Java abstractions and more specifically BeepCore-Java I was able to throw together a workable protocol that's proven to be extensible and quite robust in just a few days.

The BEEP community is alive and well!

• BEEPCore-Java - Java implementation with a BSD-like license
• BEEPCore-C - C/C++ implementation with a BSD-like license
• PermaBEEP - C implementation with a SleepCat-like license
• BEEP4j with an Apache-like license
• PyBeep for Python with an unknown, but OSI approved, license
• RoadRunner - C and Python implementation with an OSI approved license.
• Beepcore-Ruby - Ruby implementation (though just beginning) with a BSD-like license

There's an excellent IRC channel at OpenProjects with the kitschy name #beepnik.

There's the obligatory O'Reilly book, BEEP: The Definitive Guide.

But the best source for information is the Beepcore.org site which has, among other things, an excellent whitepaper on the justification and design of the BEEP protocol.

BEEP's an impressive protocol framework with even more impressive implementations.

I'm using it in a burgeoning open source project because of it's ability to multiplex bidirectional communication channels in a transparent fashion. Other features such as dynamic client/server roles, authentication, and channel encryption are just icing on the cake. The less I have to muck around with protocol state details the better!

When I first started looking at BEEP I was impressed by the spec but I was suspicious as to the quality and breadth of implementations. After looking through the high level Java abstractions and more specifically BeepCore-Java I was able to throw together a workable protocol that's proven to be extensible and quite robust in just a few days.

The BEEP community is alive and well!

• BEEPCore-Java - Java implementation with a BSD-like license
• BEEPCore-C - C/C++ implementation with a BSD-like license
• PermaBEEP - C implementation with a SleepCat-like license
• BEEP4j with an Apache-like license
• PyBeep for Python with an unknown, but OSI approved, license
• RoadRunner - C and Python implementation with an OSI approved license.
• Beepcore-Ruby - Ruby implementation (though just beginning) with a BSD-like license

There's an excellent IRC channel at OpenProjects with the kitschy name #beepnik.

There's the obligatory O'Reilly book, BEEP: The Definitive Guide.

But the best source for information is the Beepcore.org site which has, among other things, an excellent whitepaper on the justification and design of the BEEP protocol.

Sorry, might as well post the link ... http://www.beepcore.org

When I first tried to access the page I got error 500. This site could go down soon me thinks or atleast the java server pages seem to. (usually the first things togo when /.ed) So here's a hard link to their beep description.

I've also been disappointed with the lack of uptake on BEEP. It's a very cool concept.

BEEP is Blocks Extensible Exchange Protocol (RFC 3080). More details can be found at here.

When we were designing RTSP, we looked for something like this, and at the time, the options weren't very appealing. We ended up using HTTP as a quasi-base protocol. I think it was the best solution at the time, but had BEEP been available, we'd have used it in a heartbeat.

In a course I took years ago (when Interop was a small show for net-heads that fit easily in the San Jose convention center), Marshall Rose was talking about security and transports and showed us how some really twisted grad student had implemented PPP over a DNS transport just to prove it could be done.

Sadly, pretty much everyone agrees that HTTP isn't suited for the things it's being used for today, but everything gets built on top of it because port 80 is pretty much the only thing that's guaranteed to get through firewalls, most of which are stupidly configured and require the corporate equivalent of an act of Congress to get opened up.

By the way, Marshall Rose is relevant here for another reason, too: his proposed BEEP protocol is (IMO) a far better way to deal with providing a multipurpose transport suitable for a wide variety of things. There's a good BEEP Q&A document by Rose on the beepcore.org site. We should be using things like BEEP to avoid having the same arguments and reinventing the same wheels over again every few years/months/weeks. BEEP seems to be gaining traction: The IESG recently approved APEX4 the application datagram protocol over BEEP as a proposed standard, and SOAP over BEEP was similarly approved last summer. Let's hope these get through the grinder in time to do some good, and that the true Internet standard of "Rough Consensus and Running Code" prevails over corporate landgrabs by Microsoft, et al.

www.beepcore.org

Hopefully one of these shared technical developments will be the reuse of the eXtensible Registry Protocol (XRP), which is defined as a profile for the Internet-standard BEEP framework. NeuStar used hardened implementations of the BEEP framework, called "Beepcore," that my former employer Invisible Worlds developed under contract.

I don't know of any open source implementations for XRP, but these Beepcore implementations are available as free software under a BSD-style license at Beepcore.org.

............ kris

Kris Magnusson
(formerly marketing and developer relations manager for Invisible Worlds)

Hopefully one of these shared technical developments will be the reuse of the eXtensible Registry Protocol (XRP), which is defined as a profile for the Internet-standard BEEP framework. NeuStar used hardened implementations of the BEEP framework, called "Beepcore," that my former employer Invisible Worlds developed under contract.

I don't know of any open source implementations for XRP, but these Beepcore implementations are available as free software under a BSD-style license at Beepcore.org.

............ kris

Kris Magnusson
(formerly marketing and developer relations manager for Invisible Worlds)

The BEEP working group of the IETF published a P2P protocol standard last April. This is based on several years of work by Marshal Rose and several other well known IETF craftspersons. I think this is a case were Sun should consider adopting a well thought out standard rather than inventing a new one. Visit BeepCore to learn about the libraries that are being developed to implement BEEP. (I look forward to having the PyBEEP interface included in the standard Python distribution.) The site also refernces several IETF projects and commercial project that are based on BEEP.

See my earlier post in this thread.

The effort fragmented, and the working group rewrote its charter to limit its purpose to defining requirements. Their RFC's about the Common Profile for Instant Messaging (CPIM) have been published, and they should be closing down soon. The IETF instant messaging effort is now mainly split into two camps with subtly different aims.

The SIMPLE working group is adapting the Session Initiation Protocol (SIP) to serve the traditional purpose of instant messaging.

The APEX working group is developing a BEEP profile to serve as a general-purpose, low-latency, Internet-scale application messaging and presence protocol.

Both are good ideas, and neither one is enough by itself. The SIMPLE group is likely to get something up and workable quickly, but it won't be all things to all people. The APEX group, on the other hand, may take longer, but it is doing some remarkably good work and there is already a fair amount of BEEP implementation code published under a BSD license at sourceforge. See the new BEEP Home Page for the juiciest news.