We have moved to a new Sailfish OS Forum. Please start new discussions there.
10

app API model

asked 2014-01-03 20:56:53 +0200

AL13N gravatar image

updated 2014-01-03 22:04:22 +0200

I would like apps to keep an open mind and allow other apps to use services.

For this, i would like a formal API to be created for each app (submitted from harbour?) which follows some sane versioning scheme.

This would allow apps to do interact with other apps.

of course, using such API is not guaranteed to work, and thus apps who use these API will have to check if those services failed or not.

eg:

  1. games that cross into each-other
  2. games to auto-find friends from social media
  3. sky is the limit!

(of course this would also need to be handled security-wise, but that's another post)

Notes:

  1. it would be nice if this was QML accessible in a simple way
  2. also Jolla Apps could have API's like this (eg: mail/sms/etc...)
  3. even the SailFishOS core could have API's like this

Edit: someone mentioned that this is really DBUS. i have no qualms about DBUS nor am i trying to reinvent it. i'm just noting the ideas, if DBUS can/is used for this, then fine. though a formal notation for users and other app devs (and possibly security) is kind of needed (with sane versioning), in order to have stable API's to rely on.

edit retag flag offensive close delete

Comments

Sounds interesting. This could give interesting cross-working possibilities, but not being a developer, can't really say how feasible this would be. At the least, this should be optional feature and not be enforced for every single app submitted to Harbour. But this was the intention anyways?

pnuu ( 2014-01-03 21:31:34 +0200 )edit

@pnuu well, if there's an extra field on harbour app submissions on API, or something, i guess an app could just not fill it in and not export an API to be used from other apps. but sometimes if you do export some API, it ends up being used in surprising ways...

AL13N ( 2014-01-03 21:50:00 +0200 )edit

1 Answer

Sort by » oldest newest most voted
5

answered 2014-01-03 22:04:16 +0200

Venemo gravatar image

updated 2014-01-03 22:22:48 +0200

This is extremely easy to do with D-Bus; read about its concepts and docs. :)

Basically, any application (or any process, in fact) can export a D-Bus service which other processes can then call. Qt even has a module for it, which allows Qt apps to both export a service or connect to one.
In your terminology, you could think of a D-Bus service as an API and the processes calling the service could be thought of as clients of that API.

See:
http://www.freedesktop.org/wiki/Software/dbus/
http://qt-project.org/doc/qt-5.1/qtdbus/qtdbus-index.html
With Qt, basically you can make a QObject subclass and export its methods and then other processes can call them over D-Bus. It is a very powerful concept.

Note that this was already a practice which a LOT of applications used in the Maemo 5 times: an app could detect whether another app was installed / running by checking the existence of its D-Bus service and then they could provide additional features and integration with the other app by using the service.

edit flag offensive delete publish link more

Comments

yes, i knew about DBUS, but i tried to keep it impartial, in the question. In fact, the important thing is for app devs to commit to a stable API for their major versions, so that even if some apps update, that you can still have a big chance for your API's to work.

AL13N ( 2014-01-03 23:49:55 +0200 )edit

also, IINM DBUS could probably via some access policy with systemd be secured as well. probably apps could be cgrouped and possibly run as a different user? to make it a little bit sandboxed? without giving away efficiency or easyness or flexibility? (also see api security )

AL13N ( 2014-01-03 23:52:40 +0200 )edit
1

@AL13N I'm not quite sure about its security, I just pointed to D-Bus to help you with this awesome idea :)

Venemo ( 2014-01-04 00:07:56 +0200 )edit

Another +1 for DBUS.

While QML API is welcome, I'm sure other toolkits such as SDL or fully custom graphics engines will be used. In this case, DBUS should still be easily accessible but Qt only APIs wold not (at least without some serious hacking).

MartinK ( 2014-01-04 00:23:22 +0200 )edit
1

@MartinK i'm pretty sure that QML should be possible to use DBUS API calls

AL13N ( 2014-01-04 00:27:18 +0200 )edit
Login/Signup to Answer

Question tools

Follow
4 followers

Stats

Asked: 2014-01-03 20:56:53 +0200

Seen: 438 times

Last updated: Jan 03 '14