1043686 - Add an endpoint to list all the call-url generated and valid

Status: VERIFIED FIXED

(Hello (Loop) :: Server, defect)

Description

[Alexis Metaireau (:alexis)]

Starting this bug as a discussion: would it make sense to have a way to list all the call-url that were generated by an user?

I believe that would help synchro between clients for instance.

Comment 1

[James Bonacci [:jbonacci]]

This sounds like a late API change. How will this impact the current release and the overall release schedule?

Comment 2

[Alexis Metaireau (:alexis)]

This is a feature we would add for next versions of the API, it's not breaking any sort of compatibility so I wouldn't consider this a late API change.

Adam, I would like your opinion on this particular proposal, would it make sense to add this to the server APIs?

Comment 3

[Tarek Ziadé (:tarek)]

What is the scenario today if you have lost your FF environment ? Do you need to re-create a call-url if you did not save it somewhere ?

Comment 4

[Alexis Metaireau (:alexis)]

Today, there is no way to get back the call-urls if you lose them.

Comment 5

[Tarek Ziadé (:tarek)]

semi-related: on desktop it could be a sync record in Firefox Sync

Comment 6

[Adam Roach [:abr]]

(In reply to Alexis Metaireau (:alexis) from comment #4)
> Today, there is no way to get back the call-urls if you lose them.

This isn't strictly true -- to accommodate URL revocation in the case of, say, abusive calls (even if you don't have a list of all the URLs), we do indicate the callUrl as a parameter when you find out about a new incoming call: https://wiki.mozilla.org/Loop/Architecture/MVP#GET_.2Fcalls.3Fversion.3D.3Cversion.3E

(At least, that's the design -- I haven't double-checked the implementation)

But, yes, in the general case, if you don't track the URLs locally or if you somehow lose the list of URLs that you've issued, there's no way to request a new copy of them. Now that we've gone to a stateful model for URLs, it probably does make sense to have a method to retrieve them. The client synchronization use case is a good example of why this makes sense.

That said, in discussions with Darrin so far, we haven't considered URL management to be part of MVP, so I would put this further out on the timeline.

(In reply to Tarek Ziadé (:tarek) from comment #3)
> What is the scenario today if you have lost your FF environment ? Do you
> need to re-create a call-url if you did not save it somewhere ?

For non-logged in users, losing your environment means all your previously-issued URLs become invalid. The only thing that binds a URL to your browser is the HAWK token that your browser stores. If you lose that, you have no way to assert ownership of the URLs.

For users with an identity (FxA or MSISDN), issued URLs are bound to the identity. Loss of a profile has no impact on issued URLs, which will continue to route to any device that can authenticate as the associated identity.

Comment 7

[Adam Roach [:abr]]

(In reply to Tarek Ziadé (:tarek) from comment #5)
> semi-related: on desktop it could be a sync record in Firefox Sync

I think we want the service experience to be as seamless as possible between Desktop and FxOS, at least long-term. I would hesitate to take any decisions that make this more difficult...

Comment 8

[Alexis Metaireau (:alexis)]

 
 
> That said, in discussions with Darrin so far, we haven't considered URL
> management to be part of MVP, so I would put this further out on the
> timeline.

Okay. If that makes sense to you, I can implement that on the server-side when I'll have some extra cycles, and the client can consume it later on when there is a UX experience around it?

Comment 9

[Adam Roach [:abr]]

(In reply to Alexis Metaireau (:alexis) from comment #8)
> Okay. If that makes sense to you, I can implement that on the server-side
> when I'll have some extra cycles, and the client can consume it later on
> when there is a UX experience around it?

Sure, if you don't have any higher-priority tasks. :)

Comment 10

[Rémy Hubscher (:natim)]

Attachment: Link to github PR

Comment 11

[Alexis Metaireau (:alexis)]

Comment on attachment 8474436 [details] [review]
Link to github PR

https://github.com/mozilla-services/loop-server/commit/a5fc7cd8d110ce53061ccefe1e2affcb4e1e7bdc

Comment 12

[James Bonacci [:jbonacci]]

How soon does this need to be deployed to Stage/Prod?

Comment 13

[Rémy Hubscher (:natim)]

There is no ETA it is not needed for Fx34 nor Fx35 but it will be in the next release before 2nd of September.

Comment 14

[James Bonacci [:jbonacci]]

Version 0.11.0 is out in Production.