Roundtable discussion: Jolla Harbour APIs [answered]

asked 2014-02-12 12:35:34 +0300

14841 ●130 ●160 ●170

updated 2014-02-12 12:48:19 +0300

This thread is intended as a follow-up to the community roundtable discussion about APIs at FOSDEM 2014:
https://together.jolla.com/question/11303/are-you-going-to-fosdem-2014-irl-floss-meeting-in-belgium/#post-id-13864

It is both the interest of Jolla and the developer community to have as many APIs available for Harbour apps as possible. The main point of this discussion is to find a way to deliver usable APIs that best suits the interests of everyone.

Here are the areas of discussion:

Qt APIs - Some of them are not stable yet and Jolla is reluctant to allow them in harbour
Nemo APIs - Same story, not all of them can be considered stable
Jolla specific APIs - AFAIU Jolla tries to keep the number of these to the minimum

Here are the most prominent ideas that came up:

Let's say Jolla allows us to just use unstable APIs in the Harbour.
In this case, the API will change and become stable at some point. In any case, eventually everyone will have to adapt their applications to the new APIs. This is a problem for many developers (especially companies) that don't have the resources to adapt their apps to new APIs all the time.
Let's say Jolla decides to develop their own API for something and commits to keeping it stable.
Then the problem is twofold: 1. once the thing becomes stable in its respective upstream, Jolla will be forced to maintain two different APIs that both serve the same purpose. 2. Apps using the Jolla-specific API will be harder to port to other platforms.
Let's say Jolla decides to support the unstable APIs and maintains them for a few more releases.
Here the idea is to allow usage of an older version of an API for a number of releases. In this case, devs don't have to adapt their apps immediately and are given some time to do so. Problem is that they will have to adapt the apps eventually and Jolla will still have the burden to maintain two versions of the same API.

Some other points of interest:

What should happen if myapp depends on mylib - and then mylib disappears from the next OS update? Should the app be uninstalled, or should the update not be installed until the user uninstalls myapp?
What should happen if a developer abandons their app so that even if they're given the time, they don't adapt their app to new API versions?

If you have ideas to solve these issues or can come up with a good compromise, please chime in to this discussion!

edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by eric
close date 2015-01-21 10:07:14.620656

1

answered 2014-09-01 17:30:35 +0300

Mr E
11 ●1 ●2

Use "KDE Frameworks 5". KDE Frameworks 5 is QT oriented with Qt Addon libraries. As a result I should like to get the following from "KDE Applications" to Jolla: - Marble with vector graphics - KDE-Telepathy - KWrite - Calligra Suite

edit flag offensive delete publish link

6

answered 2014-08-19 12:24:51 +0300

r0kk3rz

10112 ●108 ●186 ●181

The problem I can see for Jolla is that if they continue the current restrictions on Harbour, developers will continue to release apps on OpenRepos instead.

This means that whatever problems they are hoping to avoid by not allowing many APIs are likely to occur anyway, because a significant amount of their userbase will have installed apps from OpenRepos because what they want isn't available on Harbour. Mitakuulu is a prime example of this.

If they remove some of the restrictions for the more popular OpenRepos apps then at least they know what is out there, what libraries it uses, how many people might be affected by changes etc

edit flag offensive delete publish link

Comments

We need Harbour and OpenRepos both. Harbour is the save harbour, I can trust. OpenRepos is like the real sea, requiring a experienced sailor. I'm sailing in both waters, but I love the feeling of security beeing in Harbour. A prosperous Harbour needs development to supporting bigger ships. I hope Mitakuulu will mooring soon.But the Harbour must be a save harbour.

utkiek ( 2014-08-19 22:05:37 +0300 )edit

yes, most users like to play it safe initially. but there is a patience limit.. after which, they wouldn't mind taking risks to get things done.

An example: {after 3 months: 1st non-harbour rpm (mitäkuuluu); 6 months: Warehouse; 9-12 months: starts applying random patches to alter stock ui}

User ( 2014-08-20 07:47:03 +0300 )edit

1

There will always be a place for OpenRepos, but my point is that people will install the apps they want whether they meet the harbour rules or not.

so either they relax the rules a bit, or they will have to deal with everyone using third-party repos instead of just a small minority who like to tinker anyway.

r0kk3rz ( 2014-08-20 12:23:20 +0300 )edit

0

answered 2014-02-16 19:53:04 +0300

This post is a wiki. Anyone with karma >75 is welcome to improve it.

updated 2014-02-17 20:50:53 +0300

00prometheus
13308 ●135 ●174 ●152

The open source way is to contribute. Instead of working on their own APIs to cover for deficiencies and lateness in the Qt APIs and Nemo APIs, why not contribute instead? Rather than wait for upstream to get the job done, Jolla can use their good project management and professional developers. Surely they must be able to help fix what needs fixing for the Jolla, just as a private contributor often does when they see something they want fixed.

Edit: OK, I got this wrong, see comments.

edit flag offensive delete publish link

Comments

Yes, they are already doing this. This is not the problem. The problem is what to do until those APIs become stable. (Which is going to take a long time, even with their contribution.)

Venemo ( 2014-02-17 10:25:35 +0300 )edit

1

Oh, OK, thanks, I was looking at the wrong scale of things. Hmm, I just deleted and undeleted my Answer, there might be someone else making the same mistake, so I will leave it in there with a warning comment.

00prometheus ( 2014-02-17 20:49:33 +0300 )edit

4

answered 2014-02-16 18:24:47 +0300

qwazix
2310 ●27 ●37 ●42

There are two ways of application development: the linux way (dependencies maintainership etc), and the other way (huge packages of statically linked things). If I was to bet I would say that the linux way would never work, due to continuous api changes, cost of maintenance etc. but here is debian with 37500 packages developed and maintained this way.

Jolla must choose one of those two ways, either encourage static linking and minimal use of OS APIs which should be maintained religiously and stay backward compatible, or treat Sailfish as a proper linux distribution, and enable everything that would be acceptable in any desktop distro repository, throwing out packages that stop working due to lack of maintenance.

I think developers have already voted with their work which of the two they like more, as I see far more OpenRepos announcements on my Twitter feed than Harbour announcements.

edit flag offensive delete publish link

Comments

1

Hmm, I'd say take a look at the Linux desktop market share now after 20+ years to get a hunch that the Linux way neither attracted users nor big developers.

pycage ( 2014-02-16 20:14:25 +0300 )edit

It attracted server and web developers, what is your point?

qwazix ( 2014-02-16 22:50:39 +0300 )edit

1

One caveat - Debian is a desktop linux distro, with a lot slower development cycle, and a huge share of common libraries. Mobile is a lot more diverse when it comes to dependencies, and on a lot faster development cycle. Also, that 37500 is packages so a lot less in terms of apps. While it can be used for that purpose, Linux desktop-style package management is too fat and inefficient compared to what mobile of today needs, but that's a different discussion :)

achipa ( 2014-02-17 00:06:47 +0300 )edit

maybe, but then again, it's what kinds of apps you want. There is no chance a small community like us would be able to produce high functionality production apps like, say, gimp or libreoffice without the help of the thousands of libs and packages out there, plus the space savings of dependencies really do matter on mobile. Installation times are really a minor issue, and I think that this is apk's/click's only advantage. Jolla already supports apk, native should have more power than that.

qwazix ( 2014-02-17 23:48:04 +0300 )edit

The fact that there is "far more apps" on openrepos does not mean it's the best solution in the long run. I am almost sure sooner or later openrepos will give conflicts when sailfishos upgrades. Since openrepos have no policy et all what thirdparty libs app uses. Example I'm for sure not intrested to see two versions of python intepretors running cause some devs prefer use python2 instead of python3 or pyside instead of pyotherside and so on. We devs has too think of the endusers too.

mike7b4 ( 2014-02-17 23:51:02 +0300 )edit

3

answered 2014-02-13 08:08:35 +0300

k79
591 ●8 ●13 ●16

What should happen if myapp depends on mylib - and then mylib disappears from the next OS update? Should the app be uninstalled, or should the update not be installed until the user uninstalls myapp?

IMHO, all broken dependencies shall be identified before the update is installed. Then the updater shall present to the user the list of problematic apps with the warning like "If you install update XXX, these apps will be broken and unusable" and let the user to decide: proceed with the update or not. If the user decides to proceed with the update, all broken apps shall not be automatically deleted, but should be moved into special "quaranteen" place, where they can be seen by the user - either a folder on Home screen or some other place. The reason not to remove those apps, but to keep them (until user explicitly removes them) - what if the next update will fix the broken dependency? Then those apps could be placed back in use (automatically or manually).

edit flag offensive delete publish link

Comments

Agree apart from "quaranteen" place. Too over-thinking it. If developer decides to go for unstable API, he should be warned beforehand heavily that he will have 1/2 releases to migrate to new API. If he no longer cares, somebody will fill the place in the market probably.

miska ( 2014-03-20 22:54:46 +0300 )edit

0

answered 2014-02-12 18:18:48 +0300

marmistrz
331 ●8 ●15 ●19

Ad. 1. An easy option is: Unstable APIs. You can use them but you'll need to adapt to changes which will appear later. Ad. 2. Developing your own library is not a good idea. Why reinvent the wheel instead of contributing to ready some open source projects?
Ad. 3. Why should a library be removed at all?

edit flag offensive delete publish link

Comments

1

regarding 3: a library that is not maintained will at some point break because of changes elsewhere in the ecosystem. The bugs this introduces in any program that uses the library can be really nasty and is a nightmare to detect and debug. If you remove the library at least it is easy to detect why the program stopped working instead of scratching your head for hours because your sum-function suddenly only can handle numbers evenly dividable with 9.

Feffe ( 2014-02-12 22:44:27 +0300 )edit

1

... and a program that's not maintained, will at some point break because of changes in it's dependencies. Which as I see it, is the answer to the last question in the original post.

All APIs will not remain static and that will in time break some apps. Jolla have some responsibility to not break apps without warning, but in the long run. Apps that aren't maintained will not work. Broken apps should be removed from Harbour, but it's probably up to the user to remove them from the device.

evk ( 2014-02-12 23:33:46 +0300 )edit

Ad. 3. Why should a library be removed at all?

What if it's not removed but upgraded to a new version that is binary incompatible with the old version?

Venemo ( 2014-02-17 10:26:34 +0300 )edit

1

Then it will fail to work and will have to be fixed by the maintainer.

marmistrz ( 2014-02-17 19:29:58 +0300 )edit

@Venemo if ABI changed, proper way is to rename package, i.e. include ABI version in package name. or you break all currently linked packages with just one update(which ofcourse does not have any conflicts).

Basil ( 2014-02-18 11:48:11 +0300 )edit

24

answered 2014-02-12 16:04:41 +0300

achipa
241 ●1 ●1 ●3

[Posted to list, but here as well for completeness' sake]

My personal advice is - don't overthink it. The bottom line/driver is the user experience.

It's super-easy to overthink and overengineer in the hope that strong and restrictive policies will somehow protect you. In both my personal and professional experience, they largely won't, as at some point there will be a change of behaviour/policy even in those supposedly "stable" APIs or there will be that weird app that actually depended on a bug, and the framework fix broke it. Life of a platform vendor is hard.

The other thing I'd like to highlight for the cases WHEN YOU HAVE LIMITED REPOSITORY TESTING BANDWIDTH (yes, that's all caps), it IMHO shouldn't be the repository QA that tries to validate all versions and use-cases. There is a reason why in appstores it's the users who give the stars and comments, and not the repo QA. Repo QA is more about "will it start" and "will it burn your house down". If a hard-dependency disappears, uninstall. If it breaks later on, annoys, users will one-star it and it will sink to the bottom of the store search. Tough luck, life of a app developer is hard, too. What's happening right now is the exact opposite - apps that have perfectly fine user experience are turned down because they link to verboten libs (even if the app would still work fine if the lib went away). At the same time you can publish the world's most inefficient and annoying app if it uses the "right" libs and services.

Finally, there is the segment about hackability and open development. The current harbour limits are IMO worse than what we had even in the Ovi days - the intent of why some parts of the system are off limits doesn't matter, if in the end that prevents people making/getting cool apps to people - remember Aegis? That was also a "tool" to guard platform, users and developers alike. If in the end all I can make is a Flappy bird or Doodle jump, your platform doesn't stick out the tiniest bit (on the contrary) from the others - at that point it's really tempting to just go full Android and say "your problem" if an APK doesn't work on a Jolla/Sailfish device.

I can take a one-star rating with pure profanity as the comment to my face a lot easier than hard-policies that prevent me from getting (hopefully cool) stuff to people.

edit flag offensive delete publish link

Roundtable discussion: Jolla Harbour APIs [answered]

If you have ideas to solve these issues or can come up with a good compromise, please chime in to this discussion!

The question has been closed for the following reason "the question is answered, an answer was accepted" by eric
close date 2015-01-21 10:07:14.620656

7 Answers

Comments

Comments

Comments

Comments

Comments

Question tools

Stats

Related questions

Roundtable discussion: Jolla Harbour APIs [answered]

If you have ideas to solve these issues or can come up with a good compromise, please chime in to this discussion!

The question has been closed for the following reason "the question is answered, an answer was accepted" by eric close date 2015-01-21 10:07:14.620656

7 Answers

Comments

Comments

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions

The question has been closed for the following reason "the question is answered, an answer was accepted" by eric
close date 2015-01-21 10:07:14.620656