[jdev] JEP--0060 implementations?

[Bob Wyman]

Ralph Meijer wrote:
> Pubsub.com as far as I can see, is tailored to the 
> pubsub.com application, and not a generic pubsub
> service anyone can use for their own applications
> (Bob, correct me if I'm wrong).
	It is not our intention to build a pubsub service that is in any
way non-standard -- in anything other then the implementation. In other
words, we're trying to make sure that we implement JEP-0060 faithfully.
What will be different about our service is that we hope it will be
better, faster, more robust, etc. then the average pubsub service. 
	At present, we implement a content-based pubsub service which
isn't yet part of JEP-0060. However, I'm hoping that our proposed
extensions to JEP-0060 will be accepted so that what we do will become
standard.
	Currently, we're the only publishers who are authorized on the
service we implement. This makes a great deal of sense since our system
includes so a great many "experimental" extensions to JEP-0060. Thus, it
is very likely that much of the interface will change in the future as
the content-based extensions to JEP-0060 are modified in the standards
setting process. We don't want people investing a great deal of effort
into building applications that will be broken if any of our proposals
are modified before being accepted.
	In the future, we expect to be hosting quite a number of new
topics (or nodes) that can be subscribed to as well as hosting topics
that are defined by other people. Topics may be generally available or
even, in some cases, "private" in that they will be only visible based
on authentication credentials. However, we do this as a business, thus,
we expect that there will be some limitations on creating topics,
publishing, etc. Some capabilities may only be available upon payment of
appropriate fees. (This is reasonable since pubsub services typically
generate a great deal of traffic -- much more than just chat and
traditional Jabber applications.)
	Please be aware that implementing content-based pubsub is not an
easy task. To give you some idea of the problem, consider that we
currently do matching of subscriptions to published events at very high
rates. In the last few days, our server has been matching at a rate of
about 50 billion matches per day on a regular basis and it has peaked to
a rate of about 225 billion matches per day. The matching engine, in
testing, has been clocked at about 3 billion matches per second. As far
as I know, there aren't any publicly available algorithms that run at
that speed... However, such matching rates are necessary to build "real"
content-based pubsub services. Thus, I personally don't expect there to
be a great number of such systems built in the near term... On the other
hand, reasonable implementations can be readily built to handle lower
levels of traffic.
	Anyway, we're trying hard to make sure that our service conforms
to all applicable standards. It won't do us any good to have a custom
system that implements protocols incorrectly...

		bob wyman