The semantics of Gradient and XMPP URLs
Problem: a valid, authenticated XMPP entity JID includes a "resource" that is equivalent to the path and query parts of a normal URL. A Gradient URL includes the JID, but uses the path and query parts of the URL to form the IQ document request extension parameters. The result is a semantic conflict over the meaning of this part of a Gradient URL.
Possible Solution: have one resource logged in per path. Paths indicate which resource you request.
- up:
- simple, no semantic conflict. you request resources.
- down:
- we could end up with hundreds of resources per JID. No way.
- You still have the problem that the query cannot be part of the JID.
- Server-side, you have one XMPPConnection per path. This is annoying, but potentially useful for spreading load.
- Technically speaking, we should then have each viewport as a different resource too. Bleh.
Possible solution: use the JID resource for something different, e.g. load balancing. The path stays what's sent in the GET.
- up:
- less work for me.
- we have something (resources) we can play with if we want to.
- down:
- confusing.
- it doesn't feel right.
-
Possible solution: have the first /section/ of the path indicate the resource, have everything else as the path.
- up:
- Fits with established usage of resources (generally just one word)
- down:
- it's a half-way house solution that mangles the spec horribly.
Possible solution: insist that the resource is always the same (e.g. "gradient") for a service.
- up:
- easier to code
- reduces conflict to a minimum
- down:
- we remove any flexibility of S2.
- however, if we do decide to use the resource, it's going to be a lot later when (or if) the software sees some use.
I like this last one myself.
© 2006. Some rights reserved. Author: Ian Sollars.
