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]>: > 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]] *On Behalf Of *Baptiste > Durand > *Sent:* Thursday, September 18, 2014 9:16 PM > *To:* [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
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
