Re: [Beepwg] SPDY feedback
Francis Brosnan Blazquez
<I'm ccing beepwg mailling list>
This is an interesting question though I don't know if there's a
satisfactory answer ;-)
From our perspective (as BEEP developers) any effort that seeks to build
an application protocol that provides channels over the same session,
asynchronous exchange, integrated session security and integrated auth,
etc, will end up in something that is really close to BEEP...so, why
don't use it directly?
The interesting thing is that if you look at the core issues that are
being addressing at the Websocket mailling list (or at least most of
them), you'll find that most of them were addressed previously by the
BEEP working group...that led to the BEEP definition.
My overall impression is that (re-)inventing the next big thing is the
preferred approach than reusing and/or extending that is already
available (assuming we have to design something that is really different
from HTTP/1.1 infrastructure).
Another explanation that lives at the heart of your question is that
BEEP was wrongly presented (at the beginning) as a HTTP replacement
(obviously it isn't) creating wrong expectations. Some times I thing
BEEP appeared too soon...
Anyway, we will keep on using BEEP and extending our products using it
as much as we can especially because it WORKS and it has a crystal clear
definition (something we can't say usually from other definitions).
We believe it's got a great opportunity in the new changing market
(smartphones and tablets) where WEB guys doesn't have all the power to
decide what's right and what's not (or what language or application
protocol you can use which is crazy).
Cheers!
> Hi, went to <http://www.mnot.net/> to comment after a SPDY article
> appeared on slashdot, tried to leave a comment but due to use of
> script + some sign-in stuff, didn't happen.
> So, if I may email you what I tried to leave there:
> ---
> Hi,
> I'm not a web or network guy (more databases & general dev) but
> whenever spdy comes up I wonder why BEEP isn't used, as it is a lower
> level (ie. more general and less tied to any particular use) than
> http, and has a number of features that are similar to spdy.
>
> From <http://en.wikipedia.org/wiki/SPDY>: "SPDY achieves reduced
> latency through compression, multiplexing, and prioritization"
>
> from <http://beepcore.org/> "BEEP is not a protocol for sending and
> receiving data directly. Rather, it allows you to define your
> application protocol on top of it, reusing several mechanisms such as:
> asynchronous communications, transport layer security, peer
> authentication, channel multiplexing on the same connection, message
> framing, channel bandwidth management, and many more interesting
> network features. [including message prioritisation I believe]"
>
> Incidentally I've never used beep but the overlap is evident and solid
> implementations exist, I understand, so why not use it?
> ---
>
> Well, why not? BEEP was designed by the guy who did POP3, SMTP, and
> SNMP (so says wiki).
> I've cc'd this to beepcore.
>
> Maybe I'm wasting your time, but maybe not...
>
> cheers
>
> jan
>
--
Francis Brosnan Blï¿œzquez <francis...@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57
AVISO LEGAL
Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohï¿œbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.
En virtud de lo dispuesto en la Ley Orgï¿œnica 15/1999, de 13 de
diciembre, de Protecciï¿œn de Datos de Carï¿œcter Personal, le informamos de
que sus datos de carï¿œcter personal, recogidos de fuentes accesibles al
pï¿œblico o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificaciï¿œn, cancelaciï¿œn y oposiciï¿œn dispuestos en la mencionada Ley
Orgï¿œnica, notificï¿œndolo por escrito a:
ASPL - Protecciￜn Datos, C/Antonio Suￜrez 10 A-102, 28802, Alcalￜ de
Henares (Madrid).
Maik Wojcieszak
Hi Jan,
Hi Francis,
Why not BEEP ? Well, this question is interesting. I
agree with you, Francis.
What about "Why Beep ?".
Well BEEP is a construction kit and you need to be well aware of what you want to do in you communications now and in the future to end up on the beepcore.org website. If you have to decide between implementing on a TCP/IP socket or using beep, the answer is obvious at least for me, when I was at this point (about 10 yrs ago).
Beep is a Peer to Peer protocol which means communication partners are real partners as soon as the connection is established. Thinking about a new protocol is still very often related to peer to peer problems because a lot of existing protocols are client/server based. Using a client/server protocol trying to solve peer to peer problems is never a good idea. If you are sure you have a client/server problem think of an existing protocol. You'll be happy with it.
If you're at the point using multiple protocols on multiple ports in your application to do different communication with the same partners you should also rethink this strategy and give BEEP a chance. Profiles are a powerful tool in this field.
Sometimes I have the impression that the number of publications about a new "technology" has more influence on a decision process than the suitability of the "technology" for a specific problem, no matter how disappointing the content of the publication is. (ok, this is cynical..or not?)
However, building a simple protocol with beep is not as easy as it seems because it has a payload, which can be any data. This can be transported from A to B but that's it. Existing protocols already have some data layer that can be (ab)used for own purposes. Besides the capabilities of the communication itself, you should be well aware of the data you want to transport. A lot of suggestions already exist like SOAP, JSON, XML, etc.
Pick one or create your own. This is matter of taste. I've decided to interface an xml format and add a type layer that helped to avoid problems related to type mismatches (in xml 42 can be a string a float or an integer). JSON has trouble with date types and in PHP you can't decide after decoding if you have a dictionary or a list. Thinking about your data is worth the trouble you'll save time later.
After thinking about data and transport independently BEEP will be more and more the best choice for most cases.
Francis, I don't think it appeared too soon. It is a universal construction kit for user protocols that reduces development costs drastically but let's say you have hunters and gatherers within the target group, the hunters write their own code. They have the time to implement whatever they need. The gatherers pick a tool or a library to use it for their purpose as long as it (almost) fits their needs.
BEEP is in between both. Too much readymade functionality
for hunters and too incomplete for gatherers. And of course too few
publications for decision makers ;-)
Well, I don't know if this is helpful .. yet another opinion so far.
Cheers,
Maik