On Tue, Jul 26, 2016 at 2:07 PM, Sebastian Kügler <se...@kde.org> wrote: > On Tuesday, July 26, 2016 1:08:28 PM CEST Harald Sitter wrote: >> - a store REST API (of which the reference version is the ubuntu store) > > So something like this exists for flatpaks as well, and it's open source? For > snappy, we'd either have to use the ubuntu store (non-free, right?) or write > our own from scratch? > > Could you expand on the distribution mechanism?
Right, so, this is actually where the two systems diverge the strongest in philosophy IMO. Flatpak distributes via repositories. Those are for all intents and purposes like any old rpm/deb repo a file tree of stuff the client may or may not want to retrieve. They are very much meant to be distributed. So, we would have a repo, GNOME would have a repo, LibreOffice would have a repo and the user (or her distribution) has to add the relevant repos to their system to gain access to the applications inside. Ultimately I think distros will have to manage a sane default pool of repos or this is going to end in tears ;) Snaps OTOH do not use repos but some "store" which is basically a REST API provider to do ultimately the same as a repo would do, albeit more "webby" as it is actually an API and not just a file tree. That by default doesn't exclude having multiple stores, the snappy team however sounded a lot like they want to keep it central-entity by default. Their point being that the user shouldn't have to go to KDE, GNOME, LO... to get access to their stuff, their stuff should simply be in a central store that would always be enabled. It's basically the equivalent of the Google Play store. The ubuntu store API thingy is apparently free though [1] there also is an example simple implementation [2]. I think the biggest problem here isn't so much the stores concept in and of itself, it's that the current snapd only can use one store at a time, which makes it awkward if a distributor doesn't want to use the Ubuntu store for whatever reason. Arguments can be made for either approach. In the end I hope we'll see a mushed together version. Fully distributed will likely get on people's nerves and at the same time fully centralized will probably raise eyebrows WRT trust and control. [1] https://github.com/snapcore/snapweb [2] https://github.com/noise/snapstore HS
