[standards-jig] JabberNG (Jabber over BEEP) (was: JEP-0017: Naive Packet Framing Protocol)

Dave Smith dizzyd at jabber.org
Sun Feb 3 00:17:11 UTC 2002

On Fri, Feb 01, 2002 at 11:20:51AM -0800, Iain Shigeoka wrote:
> Hello all,
> This is a short discussion starter on ideas for JabberNG (Jabber: Next
> Generation) inspired by recent talk of Jabber packet framing and issues


> I'd like to discuss the idea of implementing Jabber on top of BEEP.

Oy. You just want to start a discussion? That's like setting someone on
fire to help them get warm.. :)

In all seriousness, I think this is actually a good place to start the
discussion. I've gone over BEEP in the past and found it to be a little
more complex than what we have needed. However, there is a _lot_ of
interest in a secondary transport for Jabbber, so I suppose we should
take it to task.

> Is it a good idea technically speaking?

Well, technically BEEP is pretty decent; complicated, but thorough.
Personally, I classify it as a "cathedral" -- something so good, yet so
complex that most people have a hard time using it.

Now, this is just my personal opinion, but I think one of the reasons
that Jabber has survived as long as it has, is due to it's weaknesses
(technically speaking). I mean, we _don't_ have binary transport,
framing, or anything. But..the popularity of Jabber has taken off --
mostly because it's dang simple. I write XML out to a socket and read it
off the socket. 

It's my belief that this characteristic of simplicity is something we
must embrace and keep even as we move to more complex
protocols/transports. Another way of looking at it is that Jabber solves
problem in a JIT manner. However, I digress...

I don't want to use BEEP -- it's too...much. I'm all for taking the
lessons learned in it and re-applying those to Jabber.

> What are the benefits and drawbacks from a non-technical standpoint?

Well, this may sound harsh, but I haven't exactly seen BEEP as a project
which has succeeded. I'm a little wary of adopting a project that so
many people don't use.

> Will it meet future needs?

The more immediate question, is what do we need right now? I'm all about
planning for the future, but let's not get ahead of ourselves.  What
problems need to be solved in the near-term? Jabber has always been on a
curve along the lines of 3-9 months (IMHO, again). We solve immediate
problems, but we put thought into the flexibility and vitality of the
> Is it best as a JabberNG project, beep project, or completely new project?


Looking back at this email, I hope my remarks aren't too inflammatory --
they're just some personal opinions. That doesn't make them hills for me
to die on.. :)


More information about the Standards mailing list