Revision history - together.jolla.com

Roundtable discussion: Jolla Harbour APIs

This thread is intended as a follow-up to the community roundtable discussion about APIs at FOSDEM 2014.

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!

Roundtable discussion: Jolla Harbour APIs

This thread is intended as a follow-up to the community roundtable discussion about APIs at FOSDEM 2014.

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!

Roundtable discussion: Jolla Harbour APIs

This thread is intended as a follow-up to the community roundtable discussion about APIs at FOSDEM ~~2014.~~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?

Revision history [back]

Roundtable discussion: Jolla Harbour APIs

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

Roundtable discussion: Jolla Harbour APIs

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

Roundtable discussion: Jolla Harbour APIs

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