Re: [DotGNU]Re: A Proposal for a Solution (Jabber)

[Adam Theo]

barry wrote:
> Good ideas here, please see the RLS spec at
> http://www.dotgnu.org/spec/rls.htm ... it should be relatively
> self-explanatory.  I will be releasing a companion to this spec that
> explains the token scheme tomorrow.  It needs a little cleaning up
> before I release it.  Have fun. :)

ah! nice!

i see you are well on your way by taking the first step to
conceptualization: addressing and identifiers.

i basically like the plan you have there, and would like to try and
convince you to use Jabber for addressing and identifiers. it will
require a bit of 're-syboling' from the RLS there, but Jabber can do
everything you set out in it and a bit more, i believe.

now, everything i say below only goes off of memeory. i do not know any
of this for sure, but if you are serious in investigating jabber, and
are maybe willing to try a slightly different location scheme, i'll do
the hard time and research exactly how jabber does resource naming and
such, and report back to you.

jabber, in it's full entirity, follows this format in it's RLS: i use
the same notation as you do, by the way.

address@hidden<jabber.server>[/resource](?tokens)

now, taking it from left to right:

[username] is, i believe, optional. it is only optional however, if you
want to reach the jabber server and not a jabber user. translating your
proposed RLS over to jabber, i would suggest making use of the username
field here by using it for the DotGNU service.

<jabber.server> is the DNS or IP of the DotGNU server. i would suggest a
convention of using a subdomain of 'dotgnu' for the dotgnu server. that
way the jabber server (acting as the gateway and locator router) will
not get any [usernames] used by it confused with joe shmoe who jas a
jabber account at the same server to talk with his girlfriend online.

[resource] is, in the jabber world, used to signify different
'instances' of a user's account. for example, the 'kitchen' resource
could be for the network appliance sitting next to the microwave on the
kitchen counter, or the 'alert' resource could potentially be used by
others to give an emergency alarm to the user/resource, for whatever
reason.

(tokens) are in parenthesis because they are not currently implimented
in the jabber protocol. but i *just* read someone on the jabber
developers list trying to get this proposed to the jabber foundation
today, so he must be thinking along the same lines as you are. i do not
know how tokens would be formatted in his scheme, but i'm sure he would
appreciate some input from you guys if you were interested in supporting
his idea.

note that in jabber, i think tokens would be (in most cases, anyway)
best left for the message or information itself. in jabber, XML messages
are sent to and from these address@hidden/resource locators. these XML
messages are very flexible, and can take in namespaces from other xml
specs. the jabber server even as it stands now, can take any message and
route it to other servers or modules depending upon the namespace it
reads.... so again, it will be very easy for you to use jabber. as of
the v1.4 line it is very modular and will require very little if any
changing to fit into DotGNU.