[Dev] 3rd party so library installation feature

Jaroslaw Staniek staniek at kde.org
Wed Oct 16 08:19:46 GMT 2013


On 15 October 2013 14:10, 함동읍 <dongeup.ham at samsung.com> wrote:
> Dear All,
>
> I want to discuss "3rd party so library installation feature.
[..]

Hi,
Thanks for this thread. Three things that would hopefully show some gray areas.

1. I understand concerns about dependencies but this is as much hell
as the distro allows it (here: Tizen store, once it comes to life).
It's hard to offer protection with just technology, security is a
process not a product.

I am noting that _mature_ 3rd-party libraries have their maintainers,
and thus versioning, binary compatibility. If they are well
maintained, widely used, perhaps it makes sense to organize a place
for them and get them approved. What's better for security:

- having libraries in maintained versions, properly (ideally)
published and documented in some Library Store

- or have them in multiple copies statically compiled into the actual
appliactions or having them in single copy?

The latter is what we sometimes see on iOS or Android without even
noticing. From what I see in Tizen apps written for the competition,
it happens already In Tizen too, especially in games that need their
3rd-party engines to be installed this or that way.

Later in this thread it was also mentioned that a library code is
executed with rights of application which is using this library. But
if I understand correctly this is not a case against unbundling
libraries from apps; the same applies to library that was deep-copied
and bundled into app. Furthermore, updating the lib requires _action_
for all the applications that bundle the lib. And action that not
likely happens too fast.

At certain conferences Tizen is promoted as a Linux distro or alike. I
understand this is a desire of technical minds but it would be useful
to hear the voice of TSG and know the goals.

2. In the meantime I propose to look from different perspective at
what can be done and also think about _services_. Here's why.

It's useful not to confuse API of _services_ with API of _libraries_.
The latter looks quite low level.
As an example of services see some RESTful Twitter APIs, very high
level, possibly less than 50 different API items.
[https://dev.twitter.com/docs/api/1.1]

In contrast to that, APIs of libraries are much more fine-grained,
offer object orientation, support wide set of use cases. Examples:

% objdump -T libedje.so.1.7.99 | grep '\.text' | wc -l
909

% objdump -T libQt5Core.so.5.1.0 | grep '\.text' | wc -l
4677

Many hundreds!

I know many of lines there belong to nonpublic items, but still.

While I would very much see Library packages, with solution as close
as possible to the native RPM packaging, let's also consider defining
Services as a simpler use case. Perhaps in some cases 3rd-party
Services can be built as a facade for a library, and run with separate
process instance? Example is custom image processing or text
recognition services.
As mentioned by Mr. Ham, "Several apps use an app as a service app",
Android's medium for delivery of Services is the app package itself.
Not bad too, at least better than requiring to copy-paste big code
chunks and effectively forking entire projects in order to enable
software reuse.

3. Usability.
If Tizen's aim is appliance devices for nontechnical users, its GUI
shall in no way even expose the Libraries or Dependency terms. Clear
no-no for “If this app is uninstalled, [AppB, AppC and AppD] apps may
not be working well.” because I cannot explain that to my grandmother.
Instead library should stay if it's used (and maybe even if it's
unused, caching is good). Dependencies should be resolved silently. I
cannot imagine such messages to be approved in terms of UX on my Tizen
Smart Refrigerator or Smart Washing Machine product :)


-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt for Tizen | http://qt-project.org/wiki/Tizen
 Qt Certified Specialist | http://www.linkedin.com/in/jstaniek


More information about the Dev mailing list