[jdev] machine-readable server & transport list

[Jonathan Chayce Dickinson]

On Fri, 2007-08-10 at 12:00 -0600, Peter Saint-Andre wrote:
> Jonathan Chayce Dickinson wrote:
> > I think you have hit on another problem as well. How do we describe a
> > Jabber Server? 
> 
> Why do we need to list every service that a server offers? What is the
> use case? A user can register with services on other servers once on the
> network, and those can be discovered with service discovery (XEP-0030).

Oops. However, worst case scenario:

      * 5 servers support smtp-jabber.
      * 200 server almost identical (XEP Server 2007).
      * 300 servers in total.
      * User wants to get one of those smtp-jabber servers.

Can you see the users' dilemma? They would have to spend hours sifting
through 300 servers to find one of 5 (a 1-2% chance on the first try!).
Getting a computer to do a search through this O(n) scenario would be
justifiable. Even if they register with any server, they still have to
find another one.

> 
> > There is no standard mark-up language for it. XMPP
> > probably wouldn't embed (or at least, I hope not) homegrown XML
> > standards into a public RSS feed. 
> 
> Why not? Just namespace it and off we go.

Very true, but once someone decides on it we need to get it out there.
We don't want 30 million different XML standards: imagine having to
program against at least 5 (plus others you have no clue about). That's
the thing about XML, if I went and made a standard, cool. But, Romeo
<grin> decides to go and make his own because he didn't like mine, or
didn't know about it. Now we have two standards, and Me and Romeo might
not know that the others exists. With the weight of big Internet
presences like Jabber.org and W3C behind it, it's kinda hard to swim the
other direction (browser interoperability anyone?).

As a for-instance, take the vCard/hCard. Imagine if nobody controlled
it. There would be 30 implementations by now: goodbye Web 3.0.

> 
> > Somebody needs to approach the Jabber
> > Council to get a Jabber Server Markup Language into the works.
> 
> Gosh that seems like overkill.
> 
> > For the time-being, it looks like you're going to have to stick to
> > screen scraping HTML, or:
> > 
> > All known 'registerable' servers: http://www.jabber.org/servers.xml
> > 
> > I am going to go out on a limb here, but I think you should be able to
> > query an official Jabber server somewhere for the features of each
> > server, because it looks like that list of jabber servers is
> > auto-generated. Any other ideas?
> 
> That's what service discovery is for.

Imagine querying the previously mentioned 300 servers... You would
quickly run up a phone/data bill. Not to mention how long it would take.
Even if the data is gathered from those servers, you do need a central
repository. And, I might add, some of the features will only be evident
after a TLS/SASL session (e.g. binding), meaning the user will be lost
for whether or not binding is around.

> 
> Peter
> 

In the end it's not programmers who use Jabber, but users. Make life as
easy as possible for them and we could kick other, closed, IM protocols
off their roosts. Think of it this way, the user has these choices:

      * MSN: 10 Features on 1 server(farm)
      * Yahoo: 10 Features on 1 server(farm)
      * [...]
      * Jabber: 50 (bloody awesome) features disparate on 300
        server(farm)s: go find

I just don't want Jabber to go the way of HTML. HTML is a mess, in the
past there was Microsoft HTML/Javascript and Netscape HTML/Javascript.
Now there is Microsoft HTML/Javascript, Safari HTML/Javascript, Standard
HTML/Javascript, HTML 5.0, XHTML 2.0... You get the idea.

That is just a perspective of a programmer who is sick of a million
different standards that achieve the exact same thing (PLEASE! REST,
WebService, XML-RPC, Binary SOAP). Heck, this isn't even that important,
but principle will kick us all in the butt one day.

This email is too long.

 Jonathan