Ultimately, we're going to need to hand out a URL that causes a call
to happen. To make sure you are understood, are you proposing making it
more "nouny" by doing something like passing out /contact/... URLs that
lead to a page with enough smarts to create a call (using the same
token) with a REST API? I can see some advantages of this approach; one
of these /contact/... urls could lead to a tiny bit of html that is
basically like an entry in a contact list, containing presence info, an
icon, and some buttons for placing calls (it might even have a chat
window). But, this is a bit more involved, and requires more server
resources. I do hasten to point out that there is nothing that prevents
us from adding this later on, if we think it would be useful.
As for the rest of the URL, I don't think anyone is actually
suggesting we treat these as anything other than opaque URLs; the
examples are merely that. Basically, we should write the client to
handle http:// ?.net/{anything well-formed} coming back from the server
that mints call (or more RESTy) URLs.
Byron
On 2/19/14 8:32 PM, Martin Thomson wrote:
As it stands, I believe that we have two "things" here: a registry of contact
URIs, and a registry of calls. So the nouns might be /contact/{token} and /calls/{token}.
That leads to the next concern, which is that committing to a URI format is not
wise in general because that can dictate server architecture. If you do as you
describe (s/http/https), then loop.services.mozilla.com is it. You can't hand
out tokens that reference a specific deployment or server, you can't move stuff
without paying redirect or proxying costs.
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
