This is a meta bug to implement the 1.3 plan of moving the Facebook Contacts to a DataStore. The plan is: * create a standalone Facebook app * this facebook app will expose the facebook contacts as a datastore * the various apps (Contacts, Messages, Dialer, Email) will need to use this datastore Then, questions: * should we try to migrate the data from the current Contacts indexedDB to the new Facebook app ? NI Ben Turner to know if this is doable as part of an update, and even if we should do it in the general case * or should we make the user import his data again ?

Well, DataStore doesn't really do "upgrades" since it's just an Integer-to-JSON map. You just add things whenever you get them. However, I don't know if there's a good way to get Facebook stuff out of contacts currently... Gregor, is it possible ask the Contacts app to return just the Facebook contacts? Will the returned contacts have data stripped out somehow?

(In reply to ben turner [:bent] (needinfo? encouraged) from comment #1) > Well, DataStore doesn't really do "upgrades" since it's just an > Integer-to-JSON map. You just add things whenever you get them. However, I > don't know if there's a good way to get Facebook stuff out of contacts > currently... > > Gregor, is it possible ask the Contacts app to return just the Facebook > contacts? Will the returned contacts have data stripped out somehow? For facebook contacts we only store the name and an identifier that this is a FB contact in the main contacts DB. All other data is stored in a separate DB within the communications app. So I guess it would be sufficient to just import the data from the communications app.

(In reply to Julien Wajsberg [:julienw] from comment #0) > This is a meta bug to implement the 1.3 plan of moving the Facebook Contacts > to a DataStore. > > The plan is: > * create a standalone Facebook app I don't think we need that. Otherwise the current and optimized UX will be broken in a painful web activity flow. > * this facebook app will expose the facebook contacts as a datastore Contacts can expose the FB Friends as a datastore > * the various apps (Contacts, Messages, Dialer, Email) will need to use this > datastore But it will be transparent to them as we will put a shared library that will be able to enrich a regular contact with FB Data. > > Then, questions: > * should we try to migrate the data from the current Contacts indexedDB to > the new Facebook app ? NI Ben Turner to know if this is doable as part of an > update, and even if we should do it in the general case Of course, we need to migrate, otherwise it will a horrible UX > * or should we make the user import his data again ?

(In reply to Jose M. Cantera from comment #3) > (In reply to Julien Wajsberg [:julienw] from comment #0) > > This is a meta bug to implement the 1.3 plan of moving the Facebook Contacts > > to a DataStore. > > > > The plan is: > > * create a standalone Facebook app > > I don't think we need that. Otherwise the current and optimized UX will be > broken in a painful web activity flow. Jose, I'm sorry but I disagree here. One of the main point of doing the Datastore API was to be able to separate various contacts source in different apps. And we _will_ do this for Facebook, GMail, HotMail, others. > > * this facebook app will expose the facebook contacts as a datastore > > Contacts can expose the FB Friends as a datastore > > > * the various apps (Contacts, Messages, Dialer, Email) will need to use this > > datastore > > But it will be transparent to them as we will put a shared library that will > be able to enrich a regular contact with FB Data. We can do a shared library to handle various sources, yes. (In reply to Gregor Wagner [:gwagner] from comment #2) > (In reply to ben turner [:bent] (needinfo? encouraged) from comment #1) > > Well, DataStore doesn't really do "upgrades" since it's just an > > Integer-to-JSON map. You just add things whenever you get them. However, I > > don't know if there's a good way to get Facebook stuff out of contacts > > currently... > > > > Gregor, is it possible ask the Contacts app to return just the Facebook > > contacts? Will the returned contacts have data stripped out somehow? > > For facebook contacts we only store the name and an identifier that this is > a FB contact in the main contacts DB. All other data is stored in a separate > DB within the communications app. > So I guess it would be sufficient to just import the data from the > communications app. My "plan" was to be able to move the indexed db from the "communications" app to the new "facebook" app, and make this app do the migration from the indexed db to the datastore.

(In reply to Julien Wajsberg [:julienw] from comment #4) > (In reply to Jose M. Cantera from comment #3) > > (In reply to Julien Wajsberg [:julienw] from comment #0) > > > This is a meta bug to implement the 1.3 plan of moving the Facebook Contacts > > > to a DataStore. > > > > > > The plan is: > > > * create a standalone Facebook app > > > > I don't think we need that. Otherwise the current and optimized UX will be > > broken in a painful web activity flow. > > Jose, I'm sorry but I disagree here. One of the main point of doing the > Datastore API was to be able to separate various contacts source in > different apps. And we _will_ do this for Facebook, GMail, HotMail, others. > That will imply many changes, will put at risk v1.3 and will result in a non optimized UX. So IMHO it will a step backwards. and I think that the UX team would not like the result. So -1 to that. > > > * this facebook app will expose the facebook contacts as a datastore > > > > Contacts can expose the FB Friends as a datastore > > > > > * the various apps (Contacts, Messages, Dialer, Email) will need to use this > > > datastore > > > > But it will be transparent to them as we will put a shared library that will > > be able to enrich a regular contact with FB Data. > > We can do a shared library to handle various sources, yes. The library is already implemented. The fb_contact.js plus minor refactorings will do the work. > > > (In reply to Gregor Wagner [:gwagner] from comment #2) > > (In reply to ben turner [:bent] (needinfo? encouraged) from comment #1) > > > Well, DataStore doesn't really do "upgrades" since it's just an > > > Integer-to-JSON map. You just add things whenever you get them. However, I > > > don't know if there's a good way to get Facebook stuff out of contacts > > > currently... > > > > > > Gregor, is it possible ask the Contacts app to return just the Facebook > > > contacts? Will the returned contacts have data stripped out somehow? > > > > For facebook contacts we only store the name and an identifier that this is > > a FB contact in the main contacts DB. All other data is stored in a separate > > DB within the communications app. > > So I guess it would be sufficient to just import the data from the > > communications app. > > My "plan" was to be able to move the indexed db from the "communications" > app to the new "facebook" app, and make this app do the migration from the > indexed db to the datastore.

(In reply to Jose M. Cantera from comment #5) > (In reply to Julien Wajsberg [:julienw] from comment #4) > > (In reply to Jose M. Cantera from comment #3) > > > (In reply to Julien Wajsberg [:julienw] from comment #0) > > > > This is a meta bug to implement the 1.3 plan of moving the Facebook Contacts > > > > to a DataStore. > > > > > > > > The plan is: > > > > * create a standalone Facebook app > > > > > > I don't think we need that. Otherwise the current and optimized UX will be > > > broken in a painful web activity flow. > > > > Jose, I'm sorry but I disagree here. One of the main point of doing the > > Datastore API was to be able to separate various contacts source in > > different apps. And we _will_ do this for Facebook, GMail, HotMail, others. > > > > That will imply many changes, will put at risk v1.3 and will result in a non > optimized UX. So IMHO it will a step backwards. and I think that the UX team > would not like the result. So -1 to that. > In order to go forward on the Facebook will it be possible to describe: - the different workflows for facebook that lives into the communications app - the interactions that will be affected by moving the application out of the communications Of course having the code living in the communications/contacts app will always be more flexible in terms of UX/UI but I'm curious about exploring good web activity UI/UX here. Nothing prevent us to change some transitions if that will make the system better. Do you have the same concerns for gmail and hotmail or any other provider? Moving the providers out of the communications app will result into more granularity for the carriers that will ship Gaia. For example they will be able to remove one provider and to replace it with a different one that could be more accurate for the country where the phone will be released. Implementing all of them into the communications apps / contacts app does not seem a scalable solution imho. > > > > > > Contacts can expose the FB Friends as a datastore > > > > > > > * the various apps (Contacts, Messages, Dialer, Email) will need to use this > > > > datastore > > > > > > But it will be transparent to them as we will put a shared library that will > > > be able to enrich a regular contact with FB Data. > > > > We can do a shared library to handle various sources, yes. > > The library is already implemented. The fb_contact.js plus minor > refactorings will do the work. > > > > > > > (In reply to Gregor Wagner [:gwagner] from comment #2) > > > (In reply to ben turner [:bent] (needinfo? encouraged) from comment #1) > > > > Well, DataStore doesn't really do "upgrades" since it's just an > > > > Integer-to-JSON map. You just add things whenever you get them. However, I > > > > don't know if there's a good way to get Facebook stuff out of contacts > > > > currently... > > > > > > > > Gregor, is it possible ask the Contacts app to return just the Facebook > > > > contacts? Will the returned contacts have data stripped out somehow? > > > > > > For facebook contacts we only store the name and an identifier that this is > > > a FB contact in the main contacts DB. All other data is stored in a separate > > > DB within the communications app. > > > So I guess it would be sufficient to just import the data from the > > > communications app. > > > > My "plan" was to be able to move the indexed db from the "communications" > > app to the new "facebook" app, and make this app do the migration from the > > indexed db to the datastore.

Ayman, Can give you more details but the paths in essence are: Importing from Facebook, Linking from Facebook, Removing all Data from FB, Importing from Gmail / Outlook, Notifying the user how many contacts were imported. Showing the info on settings. I can imagine the number of Web Activities and the nightmare of migrating all the code we have. Also the FTU would also need to call this code ... A bunch of work to leave things worst from a end user perspective. And with a very tight deadline for v1.3 ... However in future versions, with the new Haida sheet approach, maybe we can find a solution that scales better using independent apps and moving some Contact Settings to the settings app. Thus, my proposal here would be: Migrate indexedDB to DataStore in v1.3 and start working on defining a new UX that can make independent importers and FB from Contacts. That new UX would be implemented in v1.4 and on.

(In reply to Jose M. Cantera from comment #7) > Ayman, Can give you more details but the paths in essence are: > > Importing from Facebook, Linking from Facebook, Removing all Data from FB, > Importing from Gmail / Outlook, Notifying the user how many contacts were > imported. Showing the info on settings. > > I can imagine the number of Web Activities and the nightmare of migrating > all the code we have. Also the FTU would also need to call this code ... A > bunch of work to leave things worst from a end user perspective. And with a > very tight deadline for v1.3 ... > Would it be an acceptable solution to try to move out first the code for Gmail and Live as separate applications and move Facebook to a datastore in a first step in 1.3 and move it out in 1.4 based on what we learned from moving Gmail/Live ? > However in future versions, with the new Haida sheet approach, maybe we can > find a solution that scales better using independent apps and moving some > Contact Settings to the settings app. I opened bug 920455 for the Settings. Having application settings accessible from the settings apps (or any other apps) would be good for many different reasons imho. > > Thus, my proposal here would be: Migrate indexedDB to DataStore in v1.3 and > start working on defining a new UX that can make independent importers and > FB from Contacts. That new UX would be implemented in v1.4 and on. As I said before I wonder if we can start sooner for independent importers but finalize FB for 1.4. What do you think?

oops, errased the Ni? to me whilst doing some bug admin. so putting it back.

Its not committed for v1.3 but a target for v1.3

We don't need test cases for manual testing since it's a change of infrastructure.

All the dependencies have been closed so we can mark this US as RESOLVED FIXED

Sorry, landed that patch with the wrong bug number.