Hi, since I'm a big fan of BEEP has anyone tried or started to implement a BEEP lib in D?


For BEEP see:

http://en.wikipedia.org/wiki/BEEP
http://beepcore.org/
http://www.aspl.es/vortex/ (C based lib)

--
Robert M. Münch
Saphirion AG

http://www.saphirion.com
smarter | better | faster

On Friday, 4 January 2013 at 23:44:35 UTC, Robert M. Münch wrote:
> Hi, since I'm a big fan of BEEP has anyone tried or started to implement a BEEP lib in D?
>
>
> For BEEP see:
>
> http://en.wikipedia.org/wiki/BEEP
> http://beepcore.org/
> http://www.aspl.es/vortex/ (C based lib)
>
> --
> Robert M. Münch
> Saphirion AG
>
> http://www.saphirion.com
> smarter | better | faster

For whatever reason BEEP never took off, so it's probably unlikely anyone will  write a D version of it. Google is now promoting SPDY as an alternative, and I would say it already has a lot more traction than BEEP does.

Since you are a fan of BEEP, you must know a lot more than I do about the subject. Your thoughts on BEEP vs SPDY?

--rt

I forgot to add that you can always create D bindings directly to the Vortex C library which will allow you to use BEEP with your D applications via Vortex. That's one of the cool things about D, it is fully compatible with the C ABI.

--rt

On 2013-01-05 03:40:00 +0000, Rob T said:

> For whatever reason BEEP never took off, so it's probably unlikely anyone will  write a D version of it.

I don't understand why it didn't took off. Maybe people didn't get what's the power behind it and how simple you can make your life for all network related things.

>  Google is now promoting SPDY as an alternative, and I would say it already has a lot more traction than BEEP does. Since you are a fan of BEEP, you must know a lot more than I do about the subject. Your thoughts on BEEP vs SPDY?

SPDY is more like an enhanced-HTML. So it's clearly trageted at browser and the web.

BEEP is a generic framework to desing all kind of application network protocolls. It's NOT a network protocol nor comes it with any specific protocol.

In a nut-shell you get 2^32-1 channels per connection, you can send arbitrary big messages on each channel in parallel, you can use REQ/RESP, P2P, streaming etc. model whatever fits.

The nice thing is, that you can support different version of your application protocol through different channels (profiles). So, a V2 app can still have the V1 protocol to speak to a server A and at the same time use V2 protocol to speak to a server B.

It really saves you from 90% of all housekeeping code for network stuff.

BTW: Yes, the C binding is no big deal. And the vortex lib is very matured. IMO the code is a bit complex and sometimes hard to handle. I think using D will make the implementaiton more robust and simple. That's why I asked.

--
Robert M. Münch
Saphirion AG

http://www.saphirion.com
smarter | better | faster

On Sat, 5 Jan 2013 10:56:00 +0100
Robert M. Münch <robert.muench@saphirion.com> wrote:

> On 2013-01-05 03:40:00 +0000, Rob T said:
> 
> > For whatever reason BEEP never took off, so it's probably unlikely anyone will  write a D version of it.
> 
> I don't understand why it didn't took off.

This is the first I've heard of BEEP, but my guess so far is that the main website for it:

http://beepcore.org/

Provides no explanation for how to use it beyond linking to a series of long-winded and poorly-formatted RFCs, plus the site doesn't offer a clear link to any ready-to-use lib. Either of those problems alone is enough to turn away most people.

In other words, bad marketing. Unfortunate, since it sounds like a good idea upon my first glance of it (aside from its choice to use XML for certain things, which IMO is too much of an _unnecessary_ baggage for something as low level as BEEP.)

> Maybe people didn't get what's the power behind it and how simple you can make your life for all network related things.
> 

It may very well do that, but unfortunately, figuring out how to get up
and running with it doesn't appear to be simple at all, at least
if you're looking at beepcore.org. That would certainly hinder its
ability to hit critical mass and really take off.

I don't really get why some software engineers seem to think that in 20xx they can write up a series of code-numbered legalese-esque documents (and with no formatting, and with baked-in page-breaks despite being in electronic format), and expect that people will pay attention to it.

It's kinda like how academic folk will write overly-convoluted (almost patent-like) explanations, employ other forms of obfuscation such as calling a summary or intro an "abstract" (just because some outdated standard tells them to), stick it all into a multi-column PDF, and then wonder why the non-academic side never bothers to pay any attention.

On Saturday, 5 January 2013 at 19:54:11 UTC, Nick Sabalausky wrote:
> In other words, bad marketing. Unfortunate, since it sounds like a good
> idea upon my first glance of it (aside from its choice to use XML for
> certain things, which IMO is too much of an _unnecessary_ baggage for
> something as low level as BEEP.)

I lost interest when I saw the XML mentions.

> I don't really get why some software engineers seem to think that in
> 20xx they can write up a series of code-numbered legalese-esque
> documents (and with no formatting, and with baked-in page-breaks
> despite being in electronic format), and expect that people will pay
> attention to it.

The horrific formatting of those RFCs surprised me also.

> It's kinda like how academic folk will write overly-convoluted (almost
> patent-like) explanations, employ other forms of obfuscation such as
> calling a summary or intro an "abstract" (just because some outdated
> standard tells them to), stick it all into a multi-column PDF, and then
> wonder why the non-academic side never bothers to pay any attention.

You assume they want someone to pay attention.  The real goal is slip under the radar, keep collecting the free government money for doing nothing of any import.

On Saturday, 5 January 2013 at 09:56:01 UTC, Robert M. Münch wrote:
> SPDY is more like an enhanced-HTML. So it's clearly trageted at browser and the web.

I think you mean "enhanced HTTP," as SPDY will be the first draft for HTTP 2.0:

http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0447.html

Considering HTTP is now used by all kinds of apps that have nothing to do with browsers or the web- although in large part to sneak around firewalls- it certainly won't be limited to web browsers.

On Saturday, 5 January 2013 at 19:54:11 UTC, Nick Sabalausky wrote:
> Provides no explanation for how to use it beyond linking to a series of
> long-winded and poorly-formatted RFCs, plus the site doesn't offer a
> clear link to any ready-to-use lib. Either of those problems alone is
> enough to turn away most people.

Funny you mentioned this, because a few years back when I thought BEEP was a great idea, that's exactly what happened to me. I could not easily get a grasp on how it worked, there were not even any examples. What really killed it for me was the only BEEP library I could find was broken, and I really did not want to try patching it up when I did not even fully understand what it was supposed to be doing.

> In other words, bad marketing. Unfortunate, since it sounds like a good

Try searching Google for BEEP, bad choice of name. But then we use "D"!

> idea upon my first glance of it (aside from its choice to use XML for
> certain things, which IMO is too much of an _unnecessary_ baggage for
> something as low level as BEEP.)

Yeah, XML is always a turn off for me too. JSON is better, but even still ...

>> Maybe people didn't get what's the power behind it and how simple you can make your life for all network related things.
>> 
>
> It may very well do that, but unfortunately, figuring out how to get up
> and running with it doesn't appear to be simple at all, at least
> if you're looking at beepcore.org. That would certainly hinder its
> ability to hit critical mass and really take off.
>
> I don't really get why some software engineers seem to think that in
> 20xx they can write up a series of code-numbered legalese-esque
> documents (and with no formatting, and with baked-in page-breaks
> despite being in electronic format), and expect that people will pay
> attention to it.
>
> It's kinda like how academic folk will write overly-convoluted (almost
> patent-like) explanations, employ other forms of obfuscation such as
> calling a summary or intro an "abstract" (just because some outdated
> standard tells them to), stick it all into a multi-column PDF, and then
> wonder why the non-academic side never bothers to pay any attention.

We should though look into the mirror wrt to D. I'm not suggesting that D is anywhere near as dysfunctional, it is not, but there's plenty of room for improvements. The worse we can do is not think so.

--rt

On 01/05/2013 09:07 PM, Joakim wrote:
> You assume they want someone to pay attention.  The real goal is slip under the
> radar, keep collecting the free government money for doing nothing of any import.

Most academics would love attention (which usually gets you more money) and would love to be doing something of import.  The problem is that if you don't get sufficient publications in the right journals or conferences, with their mandated publication formats, you don't get the career brownie points required to keep getting funding (government or otherwise).

It's lock-in via the requirements of the funding organizations, unfortunately. :-(

On 2013-01-05 20:15:31 +0000, Joakim said:

> I think you mean "enhanced HTTP," as SPDY will be the first draft for HTTP 2.0:
> 
> http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0447.html
> 
> Considering HTTP is now used by all kinds of apps that have nothing to do with browsers or the web- although in large part to sneak around firewalls- it certainly won't be limited to web browsers.

Well, yes, but I don't think HTTP is useful nor the way to go for everything. Same as web-apps, I just don't like them.

But anyway, it's a taste of style and there is no right or wrong.

I'm only interested in being more productive than all the others. So, using BEEP I'm just there when others are still fiddling around with a plentora of technologies.

-- 

--
Robert M. Münch
Saphirion AG

http://www.saphirion.com
smarter | better | faster