Opened 4 years ago

Closed 8 months ago

#11774 closed task (no change required)

Investigate the potential of a web app store for HaikuDepot

Reported by: richienyhus Owned by: haiku-web
Priority: normal Milestone:
Component: Website Version:
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Investigate the potential of a web appstore for HaikuDepot-Desktop and HaikuDepot-Web.

Ubuntu has both a desktop frontend and a web frontend that communicate to a web backend. When a user clicks the download button on the website, the button is linked to an unofficial apt:// uniform resource identifier that has been set to be opened on Ubuntu with the Ubuntu Software Center. The name of the requested package is extracted from the uniform resource name and user can then then install the software via the Ubuntu Software Center with only a confirmation of their request.

Example: https://apps.ubuntu.com/cat/applications/banshee/

This could be modified to use the HaikuDepot api and could communicate with depot.haiku-os.org website to pull icons, screenshots, rating and etc into this web frontend.

The the web app is written in python (django?) and is under the GNU Affero GPL v3 licence and the code can be found here: https://launchpad.net/ubuntu-webcatalog

An alternative is the FirefoxOS Marketplace, which is written is javascript, is under the MPL and its Code can be found here: https://github.com/mozilla/fireplace

The website is here: https://marketplace.firefox.com Example app: https://marketplace.firefox.com/app/facebook-1

Change History (5)

comment:1 Changed 4 years ago by waddlesplash

I think this is a good idea, but we need something slightly more unified with the main site (theme-wise, and maybe even account-wise too if that's possible) so I'm not sure if we can reuse any of those web applications...

comment:2 Changed 4 years ago by richienyhus

The Ubuntu one (which is django based) has similar dependencies to our pootle translation tool and to a django based open source QA web application that I stumbled upon (if we can't use the TestRail QA tool). This could make life easier for system-admins by simplifying the knowledge required for upgrades and maintenance by having an identical software stack for all 3.

The theme for the Ubuntu web app is found in its repo so we could edit it to fit.

But I do understand what you mean about needing more unity in our themes, which is somewhat connected to how we desperately need better navigation between different sub-areas of the project.


As for unifying the accounts, we have option of using FreeIPA and friends, ForgeRock's Open Identity Stack or Atlassian's Crowd ID server. The first two are open source software, while the last one is proprietary, but with the codebase available in a private bitbucket repo.

There is a ticket somewhere here on trac that covers the creation of a unified HaikuID that would merge all accounts into one, plus the ticket also lists a few more ID tools which do not meet that particular requirement.

comment:3 Changed 4 years ago by pulkomandy

What about OAuth, OpenID and friends for authentication?

As for the web app, I'm not very convinced by the idea that we should make a website our main way to discover native software. One of the strength of Haiku is the tight integration of apps with each other, which we currently can't provide with a web application. So, I would let HaikuDepot (the native app) be the main way to discover and manage software (no need for 2 separate apps when one will do). However, having a way to show haiku apps to people not (yet) running Haiku would be nice. I don't know if this is up to us or to the app developers.

There is also the problem that we desinged HaikuDepot and the package system to work with multiple repositories, not just HaikuPorts. If that works as planned, there would not be a single central website with all the apps, but rather many sources of packages. In that case, HaikuDepot will be able to gather the data from all package sources, but maybe a website wouldn't.

comment:4 in reply to:  3 Changed 4 years ago by richienyhus

Replying to pulkomandy:

As for the web app, I'm not very convinced by the idea that we should make a website our main way to discover native software. One of the strength of Haiku is the tight integration of apps with each other, which we currently can't provide with a web application. So, I would let HaikuDepot (the native app) be the main way to discover and manage software (no need for 2 separate apps when one will do). However, having a way to show haiku apps to people not (yet) running Haiku would be nice. I don't know if this is up to us or to the app developers.

Since the web app would also be getting all of its dynamic content from HaikuDepot Server and it would let HaikuDepot Desktop handle software management after the hpkg:// handshake, it would simply be providing an alternative means of software discovery and filtering that would be considered inappropriate feature creep if added to HaikuDepot Desktop.

This could equate to it only showing GUI apps, so that all libraries and command line applications would be treated merely as dependencies that HaikuDepot Desktop downloads along with the GUI application (after HDd informs the user). Humdinger also came up with some unique filters for end users on the mailing list.

There is also the problem that we desinged HaikuDepot and the package system to work with multiple repositories, not just HaikuPorts. If that works as planned, there would not be a single central website with all the apps, but rather many sources of packages. In that case, HaikuDepot will be able to gather the data from all package sources, but maybe a website wouldn't.

This webapp would have a hard dependency on HaikuDepot Server. 3rd party software repositories would either have to have their own HaikuDepot Server installation, roll their own website with only static content like Haikuware (but replacing download links with hpkg:// handshakes) or they would need to get the repository added to the official HDS.


Replying to pulkomandy:

What about OAuth, OpenID and friends for authentication?

That is perfectly fine for a single website, but they alone are not sophisticated enough to create the infrastructure for a unified HaikuID. Identity stacks simplify the maintenance of this infrastructure, such as how Crowd provides a optional OpenID server, while on the other hand the Open Identity Stack includes a server for the newer OpenID-Connect, LDAP and more. It is basicly groupware but for highly scalable access, ID and privilege management purposes.

For instance Andrew Lindesay has worked hard toward making sure HaikuDepot Server is future proofed enough to be able to connect with any future identity stack. This means you could safely use the same login for all Haiku related websites (trac, drupal, pootle, HDS etc), as well as with HaikuDepot Desktop and with any other desktop app.

Last edited 4 years ago by richienyhus (previous) (diff)

comment:5 Changed 8 months ago by luroh

Resolution: no change required
Status: newclosed

A lot of development and maintenance efforts later, the stores mentioned are now gone. Likely not going to happen.

Note: See TracTickets for help on using tickets.