[Standards-JIG] Jabber external components: going out of style

Jay Carlson nop at mitre.org
Thu May 18 05:33:12 UTC 2006

Justin Karneges writes:

> On Wednesday 17 May 2006 20:22, Jay Carlson wrote:
> > > It just that I liked the old way of building external components that
> > > could be used on several servers :).
> >
> > If I'm understanding this correctly, it's no longer sufficient to let a
> > contract for an RFC 392x compliant server and then count on licensing
> > best-of-breed components from third parties.  It may not even be
> Sure it is.  The RFCs don't fully dictate your server's internal design.

Oh sure.  I'm fully aware of the distinction between internal interfaces and
interactions with the cloud.  The latter is all the IETF cares about, and I
bet you could probably track down plenty of postings of mine to WG lists
where I propose all kinds of awful hacks that would be hidden behind the
cloud edge.

> Just because some servers might be more monolithic with regards to domain
> handling doesn't mean that another server can't come along tomorrow that
> better componentized.
> It might be nice to have a powerful, standardized component protocol, but
> is a hard problem, and not really relevant to the edge protocols.  For
> it's worth, Apache modules don't work in Microsoft IIS and the world still
> operates.

Yes, but CGI (I can't believe I'm praising CGI) works everywhere, and it
covers about 80% of what people seem to want to extend HTTP servers with.
Besides some small lack of expressivity, CGI's primary problem in naïve use
is invocation performance---and FastCGI, an obvious generalization, works
almost everywhere, including Apache1, Apache2, and IIS. [1]  Given trivial
extensions to CGI, it's good enough to allow implementation of WebDAV, and
if you can implement that trainwreck, well, that's a pretty good
demonstration of completeness of interface.

In retrospect (it's been a long week already), me bringing up 392x might be
a red herring; my apologies.  But do you really want to *force* pubsub into
the complexity footprint of server implementations?

I'm out of my depth here.  I haven't implemented any of these JEPs, and I'm
currently unlikely to.  But watching this thread go by, I became alarmed at
the idea that significant functionality that we're all going to depend on is
now...much cozier with the server implementation, without a decoupling
mechanism.  Without even a crappy decoupling mechanism like CGI.

As a consumer of XMPP servers, I'm disturbed at the idea that I'm going to
be locked to a stack to get vital services I need for my clients, regardless
of my level of need for performance.  And when the next shiny service shows
up as a proto-JEP, there will already be precedent that implementers can be
required to be cozy with the server internals. [2] That's why I'm posting
ill-formed fears.  I don't know what to do about it, but from previous
experience with this class of system I will now run around with my head cut
off.  The crowd goes wild.

[1]: Of course FastCGI itself is about to become remembered a joke.  If
you're ready to pay the complexity cost of linking in the bloated libfcgi,
you might as well instead run your own HTTP 1.0 server, and let Apache
mod_proxy to you.  Protocols?  There can be only one! [/me cuts off
libfcgi's head too] 

[2] Transport-level proposals like some of the WHACKfest excepted; they have
to hang out in the server's serializer by nature.
[aim for HAL, get Google]...[aim for the stars, get GPS] --- Michael

More information about the Standards mailing list