On 6/19/14 09:25, Mark Banner wrote:
A few follow-up comments having been looking through some of the bugs:
Getting Call Information
--------------------
The mix of "GET /call/{token}" and "GET /calls?version=" is confusing
- to know which calls we have incoming, we have to get /calls, but the
new "GET /call/{token}" is going to give us the part of the
information we need to display before the call is accepted.
I'll see if I can clarify the language here, but these serve two very
different purposes, and don't ever make sense for the same party to do.
GET /call/{token} for outgoing calls. It is what a link clicker would
access to find out who he is about to call. Consider the case in which
you send me a link and Eric sends me a link, and I save them off for
later use. Then, at some point in the future, I try to call you with the
link, but get the wrong one. This is the call that is going to allow the
link-clicker interface to tell me that I'm about to call Eric instead of
you.
GET /calls?version= is to get information for incoming calls.
Extra Call Information
------------------
According to
https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/#call-incoming-unknown
we should have the date the url was generated - I don't see that in
the docs currently.
Good catch. Thanks.
Which Calls
----------
Should we also change /calls?version= to only ever return one call?
Currently if two incoming calls came in close together, we'd be
getting duplicate information for the second call.
The list of calls at any given moment should only include those calls
that are currently in an alerting state -- that is, they've been
initiated, but the caller hasn't abandoned the call; the caller has
neither accepted nor rejected the call; and the server has not timed-out
the call.
In other words, the only way you'll see two records is if two people are
actively sitting around waiting for you to answer their calls. And, in
that case, I think we're going to want to tell the user that they have
two incoming calls right now, and give them the ability to answer the
one of greater interest to them.
In other words, the calls you get from /calls?version= should ideally
represent only those calls that are in active setup at the moment.
Call URL generation and identification
------------
In "POST /call-url" I believe the callerId parameter should now become
optional or removed, as the user may or may not specify it.
The discussions with Darrin so far have included ideas like having the
client put randomly selected names (e.g., adjective/animal pairs) in
when the link generator does not specify one.
Although, I'm actually a bit puzzled, as I thought in an earlier
version of the document, you could specify the caller id and duration
separate to getting the call url, but this seems to have been lost.
That's what "POST /call-url/{token} does -- it allows adjusting URL data
after the fact. So, for automatic generation, the client uses "POST
/call-url/" with information that it automatically selects (i.e.,
without user intervention). The user can then, if he so chooses, modify
that preselected information, which causes a "POST /call-url/{token}"
call to update the information on the server.
--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
