mlin at mlin.net
Mon May 6 09:13:46 UTC 2002
Hi Rob, thanks for pointing this out.
I think Jabber and Elvin are two platforms that have a lot that they can
learn from each other.
On the one hand, content-based pub/sub is a proven idea that has worked
in any number of enterprise applications. One example is the IBM Gryphon
broker (http://www.research.ibm.com/gryphon/Gryphon/gryphon.html), which
was used, ironically enough, at the Australian Open to push realtime
score information to over 50,000 concurrent clients. (Shameless plug:
the client was written in Sash, the project I work on at IBM). In this
sense, I would claim that Elvin's routing system is not bringing
anything which, at this point, is _fundamentally_ new. To be fair, of
course, if Elvin was started in 1993, then surely it was quite
innovative at the time.
DISCLAIMER: The following is Mike Lin's opinion, and is presented in no
way, shape, or form in the name or under the auspices of IBM.
One of the things I see unfortunately, no, tragically, no, fatally
hampering Elvin is that it's not free software. You have to license it
and probably pay a lot of money to use it for commercial applications.
So an enterprise can pay sum X to this unknown Australian DSTC company
for rights to use Elvin on an "as-is" basis, or they can pay, say, IBM
Global Services sum Y (Y>>X) to not only provide a proven product, but
set it up for them and provide all sorts of "Five Nines" guarantees.
Truth be told, for a large enterprise, if you are willing to pay sum X,
you are probably willing to pay sum Y. Where neither is free software,
the success comes down to whether IBM or DSTC is the better salesman
(i.e. is better at making money), and I would conjecture that IBM is far
better at it. I think it is a simple reality that, where neither is free
software, the technical merit of either product has little to do with it
(not to imply that Elvin is of greater technical merit than Gryphon or
Why could Elvin succeed if only it were free software, or, rather, why
_should_ Jabber suceed _because_ it is free software? For either project
to achieve its aims, ubiquity is pretty important. (Almost) Everybody
has to use Elvin or Everybody has to use Jabber - just like Everybody
uses sendmail (or at least SMTP) for e-mail, and then the world is
awesome. But Everybody is not going to pay DSTC. If you're
non-commercial or academic, fine, you'll use Elvin and be happy, but
_not everbody_ is non-commercial or academic. So Elvin could not achieve
ubiquity. But Everbody can use Jabber, and be happy.
But it may seem like the same argument I raised about commercial
megaconglomerates being the better salesmen would hold for Jabber as
well as for Elvin. I would claim that this is not true - here, the
technical merit can win out, because Jabber is free software. Say IBM
Global Services wins a contract to provide a messaging solution to some
customer. They have a choice between an in-house product or some
well-established, stable free software. Obviously there is motivation to
sell the in-house product. However, I would claim that the company makes
the vast majority of its profit from the service and support portion of
the contract, rather than from the one-time licensing of its software
product. IBM, for example, will make a lot more money by having its
services division set up Linux and Windows and anything else the
customer wants rather than trying to get everyone to use AIX and OS/2.
IBM's services division as a direct result makes a heck of a lot more
money than its software group . But it pushes Linux harder than Windows
for two necessary reasons - (1) it's for the most part better
technically, and (2) Microsoft doesn't get a cut of every contract. If
Linux were better than Windows but you had to pay Linus or RMS for every
copy, it would have gone nowhere fast. The fact that Linux is free
software is the enabling reason for allowing its technical superiority
to make it preferable to both customers _and_ service providers. I don't
want to think about how many awesome - incredible - feats of technical
innovation have passed away unnoticed and forgotten because they didn't
Now, what Elvin does have that we should find very interesting, is that
they have laid out the same federated architecture that we have forseen,
with relatively small intercommunicating servers administered at the
site level. In this sense, they are light years ahead of us just in
terms of having concrete implementations. I think we would do well to
read through the papers that the Elvin project has published, because
there are definitely a lot of things they have already ironed out that
we would have had to ourselves. It is worth noting with Elvin
specifically however, that content-based pub/sub is extremely hard to do
in a federated environment for reasons that should be pretty clear: with
a global network, you can't republish all messages to all the federated
services, because that defeats the purpose and doesn't scale. So how do
you know what to republish to whom? I don't know how Elvin has solved
this problem, but if they have really satisfactorily done so I would be
What I think Elvin could gain technically by looking at Jabber is the
XML protocol. I think a lot of people underestimate the importance of
this. I'd be preaching to the choir to go in depth about why this is so
good, so I won't.
So, in summary, we can learn a lot from what Elvin has already done. If
Elvin were free software, I would probably try to get our two
communities to work together and maybe even somehow unify our efforts.
Tragically, Elvin is not free software, and I think going up against the
likes of IBM, Sun, Oracle, Microsoft, or any other bigwig that provides
a pub/sub solution in the commercial arena, it is just going to get
I do, however, think, that looking at Elvin has bumped pub/sub up a few
notches on my list of priorities for Jabber.
On Sun, 2002-05-05 at 23:48, Robert Norris wrote:
> Has anyone used this in the past?
> >From the introduction:
> "Elvin is a notification/messaging service with a difference; rather
> than messages being directed by applications from one component to
> another, Elvin messages are routed to one or more locations, based
> entirely on the content of each message."
> I'm still looking at it, to see if we can steal any ideas ;)
> Robert Norris GPG: 1024D/FC18E6C2
> Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
More information about the Standards