Confirmed users
821
edits
(/* Day 4: July 7th) |
|||
| Line 173: | Line 173: | ||
=== Day 4: July 7th === | === Day 4: July 7th === | ||
====Steve==== | |||
* {{Bug|1169573}} - [Messages][NG] Lay out Messaging service structure | |||
** Polish the patch with unit test for another review, and not sure how we could start the test. | |||
* {{Bug|1179628}} - [Messages][NG] Lay out Settings service structure | |||
** We decided to split the 2 methods into views and create settings service, mozSettings shim and mozMobileConnections shim separately. | |||
* {{Bug|1167144}} - [Messages] Reduce the use of Threads.active and Threads currentId in conversation view. | |||
** Work on the {{Bug|958105}} for draft timestamp issue first. | |||
* {{Bug|958105}} - [Messages][Drafts] Creating a draft should not change the thread's timestamp | |||
** Will give a patch to ignore the timestamp change while updateThread for draft case. | |||
Today: | |||
* Update messaging service prototype. | |||
* Feedback for navigation work. | |||
* Patch for draft timestamp fix. | |||
* Reply some more thought about settings part. | |||
* Update the patch about reducing the use of Threads in conversation view. | |||
====Julien==== | |||
* mostly worked on the navigation patch ({{Bug|1162030}}); added more comments, did some final changes, add comments on github, asked feedback. | |||
* reviewed a contributor patch for {{Bug|1153883}} (rewrite some unit tests using sinon) | |||
* gave more feedback to Bevis' proposal for new MobileMessaging API | |||
Today: | |||
I want to: | |||
* do reviews for sprint bugs | |||
* think about the system messages issue | |||
* pick another sprint bug | |||
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|1155534}} - [Messages][NG] Extract NewMessage view from Conversation view | |||
** No updates (in background). | |||
* {{Bug|1175503}} - [Messages][NG] Get rid of direct ConversationView dependencies from Compose component | |||
** Prepared for review (in review). | |||
* {{Bug|1179705}} - [Messages][NGA] Upgrade to latest version of threads.js | |||
** Started migration, activity shim is successfully migrated since threads has built-in Window endpoint as I wished (without fast-path though, but onmessage/postMessage is fine) :) | |||
**: (Julien) and if we need a fastpath we can implement our own fastpath endpoint, I think | |||
**: (Oleg) True :) Just wanted to note that it's good that we can migrate to new lib with minimal effort and if we want even faster solution we can implement our own endpoint as you say. | |||
** Streams are extracted to a separate plugin file and since there can be more plugins I'd suggest to change our lib structure. How about "lib/bridge/bridge(or core?).js" and "lib/bridge/plugins/(stream or smth new if introduced)/...js"? | |||
**: (Steve) Maybe simply move the plugins into specific folder and still leave main script in "lib/bridge/"? | |||
**: (Oleg) What folder do you have in mind? | |||
**: (Steve) "lib/bridge/plugins/" like you said? | |||
**: (Oleg) Sorry didn't get :) "still leave main script in "lib/bridge/"?" ---> Not sure what you meant here, either leave script where it's now or ...? Maybe we can talk on IRC if it's better :) | |||
* {{Bug|1172902}} - [Messages][NG] Use SimpleOfflineCache to cache all app resources | |||
** Looks like all _current_, dependencies are resolved now, will see if everything works now (in background). | |||
Other: | |||
* Reading Bevis's proposal, one thing that bothers me is that outgoing messages are "transactions" and incoming messages are "some other thing", honestly don't really like that. Trying to wrap up my mind on how it can be generalized if possible at all..... | |||
*: (Julien) Aren't incoming messages also transactions? | |||
*: (Oleg) "(BVS 7/7) The difference is that for incoming message, it's not a transaction but a message temporarily stored in Gecko. The scenario is" - I'm referring to this explanation... I was imagine that we'll have single method to retrieve all "pending" transactions (including not flushed incoming messages, not downloaded MMS's), but I see it's not the case now. | |||
*:(Julien) Yep I agree with you, we need to clarify this | |||
Today: | |||
* Will handle review/feedback/need-info requests; | |||
* Will work on review comments and assigned bugs. | |||
=== Day 5: July 8th === | === Day 5: July 8th === | ||
=== Day 6: July 9th === | === Day 6: July 9th === | ||