[JDEV] UIDs

[Jeremie]

> So I return your post with two more ideas. The first, an extension on your
> happy median. The second, a whole different idea from a programmer-friend
> IRL.
> 
> "user at server/transport"? I'd like my transport to be able to encode a bit
> more information than just it's name. Reason? Because I see uses for
> transports such as "guises" and special forwarders/gateways. So I suggest an
> extension that looks like this: "user at server[/transport[/transport encoded]]".
> It allows for our current UID system, extends for the transport, and
> optionally allows for more encoded information the transport needs.

Yes, I was thinking something along those lines also...

> A programmer friend of mine working on an alternative IM system said, "Scott,
> why are you screwing around with transports on the same machine? The DNS
> system is large and cheap for what 'real' servers use. Just make all the
> transports have a different DNS entry." To which grumbled something about
> not having a bunch of servers and wandered away to write this e-mail. The
> thing is, he's got a point. DNS is cheap and it's there, so why not use it?
> scott at jabber.org? If I want to send to ICQ, 12341234 at icq.jabber.org. If
> you're cheap, or can't figure out how to map servers out to the same port on
> different IPs, 12341234 at icq.jabber.org:5555. These can all be on the same
> machine talking the same jabber language. Heck, they could be the same
> "etherx" daemon (I'm introducing a new paradigm here. ;)) passing to the
> appropriate "transport" inside based off the address. Not the "transport
> information" encoded within a UID.

Hahaha :)

Well, this is almost exactly the way Jabber currently is, it just wasn't
explained very well and there wasn't a specific requirement that the names
be in DNS, *g*.

How it's implimented currently is via etherx: etherx loads the config file
and listens on multiple IP's as specified and accepts incoming fragments.
As local transports connect to the localhost:5269 they are allowed to
become recipients of these fragments and must provide names/aliases for
which domains they handle.  So the Jabber transport would connect and tell
etherx that it is "jabber.org" and would then recieve all incoming
fragments destined for jabber.org.  The sysadmin would need to map any
names that any of the transports would use to the IPs that etherx is
listening on, and then configure each transport to tell etherx which name
it is.

Etherx, when resolving a fragment recipient, first looks at the table of
connected transports and delivers immediately there, so it doesn't *FORCE*
any DNS requirements on the names the transports use. I think my
mistake thus far has to been to use that "backdoor" to address the
transports via special names outside of DNS.

So, what you're saying is basically that in the docs/man
pages/instructions/READMES, we specify that all transport names *MUST*
have corresponding DNS names.  I don't want to try and enforce it, but
this way if they botch it up it's not a design/architecture botch up :)  I
think this works splendidly, and I should probably never had tried
utilizing the backdoor anyway...

So the end result of this: jabber://userid@foo.bar.com/special-data

==> The [jabber://] is not used internally in Jabber, only in web/URI
settings where appropriate.

==> The [userid] my be dropped for special public server-only queries.

==> The [foo.bar.com] is the address of any server/transport entity in
Jabber.

==> The [/special-data] is passed to the transport to handle as it wishes
for special purposes or internal routing data.

Lovin it, if everyone is ok with this it works for me!  The only
code/architecture changes required are to pass around that [/special-data]
which I can add into etherx without too much difficulty for 0.7.

Great, thanks!

Jer