It was <2013-10-15 wto 14:10>, when 함동읍 wrote: > I want to discuss "3rd party so library installation feature.
tl;dr Technically it is possible, however, in introduces a dependency hell. > Requirement > > 1. To provide a way to download a necessary shared library from > authorized/dedicated site > > 2. If users want to use application B which uses a shared library, > they download that library from the site by themselves. > > 3. When another application C requires the same library later, users > can use it without additional download. Technically, package manager that resolves dependencies is not a problem. Basically what you describe is a package management system, like RPM. However, all my experience with such systems on different platforms (GNU/Linux, Windows) tells me that it is next to impossible to create a system (with the widest meaning of the word "system" thant incluedes all the 3rd party developers and distribution channels) that: a) supports package dependencies, AND b) allows packages to be supplied by different vendors (especially if a one external vendor depends on another's packages). > 4. When the end user tries to remove application B owning the shared > library that is required for other installed applications, the > platform should warn the user that designated applications would not > work correctly if the library is removed. I am afraid that maintaining proper UX in such case requires uninstalation of B to be denied. > 5. The platform should provide a naming service for the installed > shared library so that any 3rd party application using it may locate > and use (load) it without knowing the specific id of the owning > package/application. How the 3rd party libraries are ment to be loaded? 1) Are they going to available for dynamic linking with the system linker (/lib/ld-linux.so)? 2) Is there going to be a separate linker/launcher for applications? if 1) is True: How would you like to prevent 3rd parties from providing libraries that may override system libraries? This is a bad idea. elif 2) is True: This looks like a great load of work. else: Huh? (dlopen(3)? see below) > Considerations > > 1. Library provider > 1) Tizen app can be a library provider with specifying a tag and > embedding the libraries. > 2) Library provider specifies a tag in the manifest file. > a) <ProvideLibrary>http://tizen.org/library/name</ProvideLibrary> > b) This tag can be restricted to partner and platform privilege > levels. > 3) Libraries are located at /shared/res/ to share with other apps. Does this suggest we are going to implement our own linker? (see below) > 2. Library user > 1) Library user specifies a tag in the manifest file. > a) > <RequireLibrary>http://tizen.org/feature/library/name</RequireLibrary> > 2) Library user has to check whether the library provider app has > been installed or not. > a) The library provider app is not installed, request of > installation is sent toStore client. This is a task of package manager not the package itself. Upon installation the library user is not a running code but rather a piece of data. > 3. Platform package manager > 1) Installed apps from Store should be uninstalled anytime when > device user requests through the System settings. > a) Library provider app should be uninstalled anytime. > b) Deep relationship with library provider app and library user > is not recommended. This is where the hound is burried. If it is possible it is going to happen. If developers find it cheaper to develop apps this way, they will. > Library user app can be working without library provider app, > if needed. This means dlopen(3). Yet another degree of freedom for app developers to break things and make Tizen look bad. > 2) Package manager can extract information of provider and users > using manifest at installation time. > a) Package manager can display a warning popup to notify a > message. i.e. “If this app is uninstalled, [AppB, AppC and > AppD] apps may not be working well.” > b) If the provider is uninstalled, the related user apps can be > terminated, if needed. This isn't enough. Package manager MUST offer possibility to uninstall AppB AND AppC AND AppD together with the package that provides required library. > 3) Application libraries are located in app directory and don’t be > moved to common library directory. > a) Library path is not specified in library user app. > 4) Package Manager can support library path API using the key that > is specified in manifest.xml. So the "app-libraries" are going to be plugins loaded with dlopen(3) rather than linked dynamically with ld-linux.so. Am I right? This allows for better security as 3rd party libraries won't be visible to ld-linux.so but makes their usage much (maybe not that much) harder for developers. Developers are going to need a tool that is going to make loading libraries work a bit like under MS Windows (at least older versions). Under MS Windows to use a mylibrary.dll developer needs to obtain a *static* mylibrary.lib and link it into her programm. The lib file provides all the symbols exported by the dll files. Instead of implementation it provides stubs that open load the dll file and links its symbols to the stubs. Again, technically this is possible but brings some mess. Unlike normal ELF bineries which hold information about libraries the programme uses, applications loading "app-libraries" via statically linked stubs won't provide such information. The only way to learn it is going to be via the package manager. The way the libraries may be located (via package manager database) may also incurr noticable preformance hit. There is a discussion on this list about making applications start fast. And the difference between 950ms and 630ms is considered worth fighting for[1]. [1] https://lists.tizen.org/pipermail/dev/2013-October/000263.html -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgp0rUegv8pFX.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
