Confirmed users
291
edits
Gaia/SMS/Scrum/2.2S13: Difference between revisions
→Day 14: 22nd May
Steveck324 (talk | contribs) |
Steveck324 (talk | contribs) |
||
| Line 599: | Line 599: | ||
=== Day 14: 22nd May === | === Day 14: 22nd May === | ||
====Steve==== | |||
* {{Bug|1163955}} [Messages][New Gaia Architecture] Preparation work for moving Drafts into back-end service | |||
** Add some thought about the cache we want. Will read the feedback later | |||
* Just play about the threads library that adding another iframe into service in order to test if it's possible to set the webapi that unable to run on worker thread. But I can not figure out how to make the iframe service work... :/ | |||
*: (Julien) there is an example in the README I think: https://github.com/gaia-components/threads/#supplying-a-target | |||
*: (Steve) Yeah I just follow the example but service didn't response | |||
*: (Julien) I'd be happy to have a first look at the code to see if there is an obvious issue, but otherwise we can ping wilson. | |||
*: (Steve) Will ping him on bugzilla later | |||
* {{Bug|1167144}} - [Messages] Reduce the use of Threads.active and Threads.currentId in conversation view | |||
** I was thinking if it's possible to remove all the use of Threads.currentId/active and query the thread id from location.hash, but maybe it's not a good pattern and it migh | |||
* Gave some feedback about split for inbox markup. | |||
Today: | |||
* Discussion what we might need to do first for cache | |||
* Review Oleg's patch about inbox/conversation markup | |||
* Some tasks for background | |||
** Fix the attachment menu for closing the option menu manually | |||
** gaia-component stuff | |||
** file loading in Template.js | |||
====Julien==== | |||
* still added some answers in the API etherpad https://etherpad.mozilla.org/ng-message-threads-api | |||
* I produced a simple prototype using Cwiis' gaia-navigator: https://github.com/julienw/gaia-navigator/pull/1 ; it seems to work, now I'll try to integrate SMS' navigation with before/after-enter/leave logic. I don't know yet if I'll be able to have all steps (thinking of afterLeave here) but maybe it's not a big issue if the frame just disappears. | |||
Today: | |||
I want to: | |||
* continue looking at navigation | |||
If all this moves forward well, I could: | |||
* continue the prototype caching the thread list to a single db (including contacts/drafts/etc). | |||
* I'd like to work on the deduplication logic for network alerts, it seems important for users ({{Bug|1067938}}) | |||
====Oleg==== | |||
* {{Bug|1162027}} - [Messages][New Gaia Architecture] extract inbox/index.html | |||
** No progress (in review). | |||
* {{Bug|1162028}} - [Messages][New Gaia Architecture] extract conversation/index.html | |||
** Since I have some initial feedback, I've moved forward here (awaiting feedback/in progress): | |||
*** Made both client and server to behave like factory/signleton, it's actually good since I see threads.js creates subjectively too many broadcast channels (and not sure if all should be closed explicitly when app is terminated). | |||
*** Added all required unit tests; | |||
*** Added support for the case when we have two instance of Messages app, one - main and second is inline activity - it didn't work because activity client in the second app instance connected to service defined in instance #1 (see note https://github.com/gaia-components/threads/blob/master/lib/client/index.js#L145). Now I just create activity client & service only when app is run as activity, we don't have to do this with other system messages. So now all activity cases should work fine; | |||
*** Alternative solution can be top context/window prefixed service-name. | |||
*** Some more details on how it works in the same window: since we don't use ThreadsManager for the activity-service, it doesn't have to spawn neither worker or create iframe. When we create client it tries to find appropriate service via dedicated BroadcastChannel, since both service and client creates this channel they can detect each other, it's like sub-optimal when both client and service in the same context/window, but we don't have such situation in longterm, from the API standpoint I'd say they should support fast-path for such cases when context-bound centralized service registry is used. | |||
* {{Bug|1127398}} - [Messages] Display existing thread when sending a message using phone-number-/email-link context menu | |||
** Since this PR makes both Conversation view and ActivityHandler simpler I've just removed conflicting changes from my PR (conflict with bug 1153885) and resumed work on this bug, while sprint bugs are reviewed. | |||
**: (Julien) +1 | |||
Other: | |||
* Left more thoughts/questions on https://etherpad.mozilla.org/ng-message-threads-api. | |||
Today: | |||
* Will handle review/feedback/need-info requests; | |||
* Will work on review comments and assigned bugs. | |||
=== Day 15: 25th May === | === Day 15: 25th May === | ||
====Steve==== | ====Steve==== | ||