1034041 - [meta] Bugs needed to fully implement websockets on standalone client

Status: RESOLVED FIXED

(Hello (Loop) :: Client, defect, P1)

Description

[Mark Banner (:standard8)]

The desktop client needs to implement the websocket protocol for call-connection progress as documented in https://wiki.mozilla.org/Loop/Architecture/MVP#WebSockets_Connection_for_Call_Progress

Comment 1

[Maria Angeles Oteo (:oteo)]

Shell, Maire, what are the plans to complete this?  Desktop Loop / Standalone client to FxOS Loop tests cannot be completed without it

Comment 2

[Maire Reavy [:mreavy]]

Hi Mark -- I know we talked about this some in our standup and that pieces of this work are being done in other bugs.  Maria confirms that the user stories in Bug 1007941 and Bug 1010168 can't be tested and completed without the websocket protocol.  

Can you comment in the bug what pieces of the protocol are needed to satisfy bugs 1007941 and 1010168?  And if that work is already being done (and on which bugs) or if new bugs are required?   

Does it make sense to turn this bug into a meta?  Thanks.

Comment 3

[Maire Reavy [:mreavy]]

Mark -- The standalone app work for this is more important than the desktop client work to unblock Maria and the TEF team.  Can you call out the specific work that is needed for that and is that something that they can help with?  Thanks.

Comment 4

[Mark Banner (:standard8)]

I'm turning this into a meta bug, so that we can track the work that's needed for getting the websocket implemented for standalone mode.

Note, that some work is required on the desktop side, as otherwise we'd break the Desktop - Standalone interactions.

Leaving the need-info as I'm still working on filing some bugs.

Comment 5

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #2)
> Hi Mark -- I know we talked about this some in our standup and that pieces
> of this work are being done in other bugs.  Maria confirms that the user
> stories in Bug 1007941 and Bug 1010168 can't be tested and completed without
> the websocket protocol.  
> 

Bug 1010168 is the user story for doing the calls within the FxOS Loop client when the links are opened in a FxOS device and not within the standalone UI as should happen in other non-FxOS devices. So that one should not be blocked by this bug, which is specific to calls done within the standalone UI.

Comment 6

[Mark Banner (:standard8)]

Ok, I think all the bugs necessary are now filed as dependent. There may be more, but we can file them as we go - as we get the first bits of implementation in place.

In the dependency tree there's a few critical bugs:

- Bug 1022594 This is the initial implementation for the websockets that I'm working on at the moment.
- Bug 1045643 is the follow-up to that, with these first two combined producing the minimum support I think we need on desktop to be able to start using the server responses at the standalone end.
- I've set bug 1000273 as the first part of the standalone implementation - it takes the very first part of the information that comes from the websocket. The rest of the standalone implementation should be able to flow from that.

As I already said, there may be more bugs to file, especially on the desktop side to handle some more of the notifications from the server, but once I've got bug 1022594 implemented it'll be much clearer as to what is left.

Comment 7

[Maire Reavy [:mreavy]]

So, what's the best way to divide up this work?  I realize the standalone work can't land until the basic desktop work for websocket support lands, but if we wanted to accelerate this, folks from other groups (like Maria's/Daniel's team) could start coding on the standalone bugs in parallel with the desktop work.

Mark -- What do you see as the critical bugs to unblock basic testing of the mobile Loop app to the standalone app?  And what order should the critical bugs be done in?   Who (what skill set?) can take them?  I know you mentioned Bug 1022594 and Bug 1045643 above, and those are probably best handled by the Loop desktop client team.  What about the bugs beyond that?  What skill set is needed to work on those?  Can development start now or do we need to do more work on Bug 1022594 and Bug 1045643 before other bugs can start?  Thanks.

Comment 8

[Mark Banner (:standard8)]

(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #7)
> Mark -- What do you see as the critical bugs to unblock basic testing of the
> mobile Loop app to the standalone app?

All the blockers to this bug except bug 1000228. Though once we've got the desktop bugs fixed, any of the other bugs will allow some testing to start, though obviously it would be incomplete (I'm unsure how much the standalone app actually requires).

> Who (what skill set?) can take them?

This is all content based code, so mainly javascript, though backbone & react may be a help for a couple of bugs (e.g. bug 1000237 and bug 1000240)

> And what order should the critical
> bugs be done in? I know you
> mentioned Bug 1022594 and Bug 1045643 above, and those are probably best
> handled by the Loop desktop client team.  What about the bugs beyond that? 

I think I've got the dependencies roughly set up to reflect this, but after those two bugs: bug 1000237 follow by bug 1015074 would be my recommendation.

> Can development start now or do
> we need to do more work on Bug 1022594 and Bug 1045643 before other bugs can
> start?  Thanks.

Bug 1000240 is probably standalone enough that it could be done now. The others it would be difficult to get started on without the desktop bugs.

Comment 9

[Mark Banner (:standard8)]

Bug 1045643 has now landed in mozilla-central. It should now be possible to test some of the FFOS implementation with the standalone code.

Bug 1045643 has implemented the messages from the standalone client to the web server for the websocket, i.e. to connect and say "hello", and to send the action message "media-up" at the appropriate time.

The only response the standalone client handles at the moment is a "terminate" with a reason of "reject".

This should allow some of the FFOS side to be tested.

To test this you'll need to connect to the dev server (this is kept up to date with the latest standalone client code): https://loop-dev.stage.mozaws.net/

If there's any questions, please drop me an email, or ping me on irc

Comment 10

[Fernando Jiménez Moreno [:ferjm]]

Thanks Mark! I managed to make a call from the standalone UI to a FxOS device using the dev server. I didn't test any further scenario than a simple call, but it seems to be working fine at least for the basic case.

Comment 11

[Maire Reavy [:mreavy]]

This is a standalone bug (no uplift required).

Comment 12

[Mark Banner (:standard8)]

I'm marking this as fixed - as far as I know, the Desktop & link-clicker websocket protocol is now fully implemented, save for bug 1066522 which is hardening the websocket protocol against unexpected drops.

Bug 1066522 can be tracked on its own and doesn't need this meta bug open for it.