1163955 - [Messages][NG] Preparation work for moving Drafts into back-end service

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Steve Chung [:steveck]]

Since we want to move drafts into worker and see how it works in bridge library, it's good time to rewrite drafts method into promise base first.

Comment 1

[Steve Chung [:steveck]]

Hey,
After some experiment in bug 1162031, access the bridge frequently might not a wise choice especially when main thread is busy. I proposed another way to cache the drafts in inbox instead here[1] and might need your opinion about this.

If we still go with my original idea that move all the methods into async:
pros: 
- We don't have to wait for all drafts data return and start render threads first. Maybe we can split the appendthread to real thread and draft for the renderdraft case.
- No need to maintain another cache in inbox.

cons:
- Considering service wrapp up and setContact also need drafts, it's very likely that use found the delay update flashing more obviously.
- onThreadsRendered need to check is the drafts exist or not, which means the visual complete time will be delayed once we move it in the async method.
- Requesting service might be delayed when main thread is busy like I described in bug 1162031 comment 1 and make above 2 drawback even worse.

In the next approach cache WIP patch I make the thread rendering start after the drafts cache because each action is base on cache. Here is my conclusion:
Pros:
- Once the cache is ready, we don't have to change the current codebase a lot.
- Less thread UI update since draft data is ready while rendering thread.
- User won't see the flashing for drafts.
- Since we requesting the service before everything start, the request round trip time will be much less than busy main thread case.
Cons:
- Thread rendering starting time delayed.
- Maintain the cache. But Inbox view only have the delete thread that might change the draft. Another case is the draft change in conversation view and we might need inter-view communication for thread and cache update.
- More memory consumption for cache 

The WIP patch is only able to launch the inbox view for early profiling(in bug 1162031 comment 3). The visuallyLoaded time will increase around 300ms. I think the cold launch time regression is expected no matter which why we choose before bridge library optimized, but it would be good to know how we want to optimize drafts/threads service based on bridge in inbox view.
 
[1] https://github.com/steveck-chung/gaia/commit/66e60a32b62024910061458a77b6a08724d1894b

Comment 2

[Oleg Zasypkin [:azasypkin]]

First of all I'd like to say that I really want "asynchronous updating Inbox with drafts" to go away, jumping/blinking because of that (and because of setContact as well) is the main pain point for me.

I agree that we should render threads only when we have all drafts available and cached. Even that it's slow now I believe we should gradually make it as fast as possible by improving Gecko/threads.js and smart&aggressive caching by means of all "cache" layers (local IDB and various SW caches). + we'll have more accurate telemetry as currently we ignore drafts in performance.mark.

Like we're discussing in [1] we can probably have several services: DraftsService for managing drafts (save/delete/get/list(?)) that works with "drafts" store in local IDB, maybe ContactsService that caches contacts data in "contacts" store and "ThreadsService" (or whatever name we choose) that also has its own IDB store with cached threads. When we retrieve thread/threads from ThreadsService it can join all the data (thread/draft/contact data) and return to the consumer so that consumer is simple as possible.

At the same time I'm not sure if it's quick to retrieve data from several stores in one transaction since we don't have sql join. If not maybe we can store all that info in single store (the only duplicated data I can imagine is contact name that can be shared between 1-to-1 and 1-to-many conversations - but it's rare case I think).

What do you think?

[1] https://etherpad.mozilla.org/ng-message-threads-api

Comment 3

[Julien Wajsberg [:julienw]]

I left more thoughts in the etherpad :)

Comment 4

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 5

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(