Hi Babtiste, Well good that there’s been discussion. However I don’t think counting on people to remember discussions taken place about a year ago or expecting developers to be aware of the contents of Tizen Conference presentation is enough to communicate CAPI changes and ensure verticals adapt to those without problems.
I would expect the developer/team who plans to modify CAPI share the changes beforehand on the mailing list and in addition either contact other teams who are affected and can be identified to discuss integration plan. Like in this case you must have understood IVI needs modification. If you test all the bigger changes only in Common and with HTML5 apps would be fair to provide changes in a branch for pre-integration and testing for verticals before actually submitting them so we can catch critical bugs before releasing and coordinate the integration schedule. Alternatively you could of course also implement the changes required in verticals so problem would go away but agreeing on the integration plan is already acceptable. I really want to avoid these kind of incidences in future so does this sound acceptable for you? Anyway I agree we now need to discuss ICO HS changes required to see if we can get away with this. -Matti-Pekka From: Baptiste Durand [mailto:[email protected]] Sent: Monday, September 22, 2014 4:44 PM To: Sivosuo, Matti-Pekka Cc: [email protected] Subject: Re: [Dev] New changes : Application Framework Hi Matti-Pekka, Sorry for the inconveniences. Theses changes has discussed since a year ago. We have added CAPI, the oldest are kept. BUT they have a few different meaning now. Indeed, the goal of Multi user features in Tizen 3,presented at San Fransisco in Tizen Dev Conf. (https://wiki.tizen.org/wiki/File:Multi_Users_Presentations_TDC2014_Final.pdf) so we need to introduce some CAPI changes (to include user id in parameters of ones of them). Tizen Common will support only HTML 5 apps. So the changes are tested in this context. For now, About ICO uxf needs to be changed too. There is no fundamental big changes, API and logic are simillar The goal of this email https://lists.tizen.org/pipermail/ivi/2014-September/003281.html is to improve and apply the correct changes in ICO uxf. I'll take in charge this changes in IVI, but I need some answer to the questions written in the previous email. Sorry again for these inconveniences. BR Baptiste 2014-09-22 9:50 GMT+02:00 Sivosuo, Matti-Pekka <[email protected]<mailto:[email protected]>>: Hi, Introducing these kind of changes in CAPI can easily cause build breaks or functional issues in verticals using Common. E.g. in IVI ICO HomeScreen and System Controller might require changes to work correctly when switching to new CAPI. Have you agreed on these changes together with all Application FW maintainers to ensure there’s alignment? Has there been public discussion about these CAPI changes before implementing and submitting them or have you identified dependencies and contacted development teams/maintainers to ensure changes takes place in a coordinated way also in client components? Of course testing e.g. ICO HS against changes done before submitting them would be nice too. My point is changing things without telling anybody beforehand is not very cool. The correct way to notify developers can’t just be to send out an email after merging changes to Common and assume they implement required changes without any planning. This just does not work really well. We can decide not to accept intrusive changes in IVI for a while but unfortunately dependencies lead to growing delta quite fast. Of course I might have just missed the memo but in case not I really think next time CAPI used by verticals gets changed we must handle the changes in a more controlled manner. -Matti-Pekka From: Dev [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Baptiste Durand Sent: Thursday, September 18, 2014 9:16 PM To: [email protected]<mailto:[email protected]> Subject: [Dev] New changes : Application Framework Hello all, Since Today the Application Framework provides some news Core API. & a new way to install applications --------------------------------------------------------------------------------------------------------------------------------- CAPI Changes : So what News? Now in Tizen 3 we can install/uninstall applications for dedicated user or for all users. So the Tizen Database are duplicated. Each User has it proper database that references all applications installed for himself (only) stored in $HOME/.applications/dbspace The set Applications Databases are also used to register applications for all user (common applications ) also called Global database stored in /usr/dbspace In consequences, appid is not unique now. Indeed an application can be installed for all user and in a same time for a dedicated user. If a user makes a request to open an app (by using appid), the user's app are choosen even if an application with the same appid exists at Global level ( avaible for all users) So now only the couple of value (appid, uid) is unique. To include this, we has been needed to introduce new CAPI based on Tizen 2.X ones. All functions fixed by _usr_ with an user id in parameters is related to applications or packages Database (depending of CAPI used) of the user All functions with the same prototype of Tizen 2.X ones are related to Common/Systems Applications We also introduce a Global User concept this user is a fictive one. (In Code, we can see some reference to a GLOBAL_USER) it exist only for operating on Common Applications Databases. To give an example of what is explain before, we have in application information library and pakcage manager library. AIL : ail_error_e ail_filter_list_usr_appinfo_foreach(ail_filter_h filter, ail_list_appinfo_cb appinfo_func, void *user_data, uid_t uid); ail_error_e ail_filter_list_appinfo_foreach(ail_filter_h filter, ail_list_appinfo_cb appinfo_func, void *user_data); -> ail_filter_list_appinfo_foreach permits to apply a filter on Common applications only (related to common applications). -> ail_error_e ail_filter_list_usr_appinfo_foreach permits to apply a filter on the applications dedicated to a user (choosen in parameters). SLP-PKGMGR int pkgmgr_client_usr_install(pkgmgr_client *pc, const char *pkg_type, const char *descriptor_path, const char *pkg_path, const char *optional_file, pkgmgr_mode mode, pkgmgr_handler event_cb, void *data, uid_t uid); int pkgmgr_client_install(pkgmgr_client *pc, const char *pkg_type, const char *descriptor_path, const char *pkg_path, const char *optional_file, pkgmgr_mode mode, pkgmgr_handler event_cb, void *data, uid_t uid); pkgmgr_client_usr_install is used to install an application for a dedicated user pkgmgr_client_install is used to install an application for all users We decide to duplicated the CAPI to distinguish Global level to User's level. for two reasons; -> make integration change easier ->satisfy a Core API usage in a Core Application Context. (see diagram architecture overview) We do not consider : pkgmgr_client_install are equal to pkgmgr_client_usr_install( getuid()) because -> CAPI can be used ay System Level by daemon (and a daemon is often not associated to a regular user ) So we need to permits to manipulate database by offering two differents API (one for Global DB / 1 for user's ones). We consider that this concept to take the current user in account should be done at HIGH Level API (ie WEB API or Native API) (see diagram architecture overview) -------------------------------------------------------------------------------------------------------------------------------------- Pkgcmd new option / Backend for Widget Apps We add ability to install web apps through pkgmgr-server so now pkgcmd binary is able to manage applications by using package Manager CAPI we are going to add -G option that permits to install application for all users. (coming soon next week). ---------------------------------------------------------------------------------------------------------------------------------------- Please find in attachment the list of added CAPI For your information :During The Linux Con at Dusseldorf Sabera Djelti will present a global overview of theses changes. For additional informations : please take a look on the wiki https://wiki.tizen.org/wiki/Multi-user_Architecture https://wiki.tizen.org/wiki/Multi-user_AMD BR Baptiste and Sabera -- Baptiste DURAND Eurogiciel Vannes/FR --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- Baptiste DURAND Eurogiciel Vannes/FR --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
