[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Detecting appstream scheme support ; end-user-oriented "About AppStream" page (was: Re: Add "Ins
From:       Aleix Pol <aleixpol () kde ! org>
Date:       2016-12-19 3:02:04
Message-ID: CACcA1RoE3-Gw7ptdnE1r7f+3fNyutdxdG0Ny=j2dYOVhJn1jdQ () mail ! gmail ! com
[Download RAW message or body]

On Mon, Dec 19, 2016 at 3:38 AM, Friedrich W. H. Kossebau
<kossebau@kde.org> wrote:
> Moving to kde-devel for more input by app developers:
> 
> For the current testing entry with an appstream: url on KDE pages see the
> right box on https://www.kde.org/applications/utilities/okteta/
> 
> But it is unclear if "AppStream" works here with most end-users. Please read
> on below and then give your comments/2 cents :)
> 
> Am Montag, 19. Dezember 2016, 01:30:39 CET schrieb Matthias Klumpp:
> > 2016-12-19 1:00 GMT+01:00 Friedrich W. H. Kossebau <kossebau@kde.org>:
> > > Am Sonntag, 18. Dezember 2016, 22:50:23 CET schrieb Albert Astals Cid:
> > > > El dissabte, 17 de desembre de 2016, a les 0:17:22 CET, Friedrich W. H.
> > > > 
> > > > Kossebau va escriure:
> > > > Is it possible to detect if the browser has a handler for the appstream:
> > > > scheme and if not don't show the link at all?
> > > 
> > > At least from a quick search there is no simple querying of the supported
> > > protocols possible. Only saw hacks of the kind which made me try to stay
> > > out of web development.
> > > 
> > > I would agree only showing the link active in browsers where the protocol
> > > works would be nicer. I can just tell myself e.g. irc:// urls in the same
> > > box also have a similar fate.
> > 
> > I am actually rather happy about that, the less information a browser
> > exposes to the webpage by default, the harder it gets to use the
> > information for tracking or to detect vulnerable systems.
> > 
> > > @Matthias & Co: What other web pages/sites are already making use of such
> > > appstream links? How do they handle it?
> > 
> > So far I've only seen very few, mainly on Wiki pages or private pages
> > at GNOME. All of them show these links unconditionally.
> > What you could do is detect whether the user is running Linux and if
> > not, hide the link. As of no, there is no Windows client consuming
> > this data that I know of.
> > 
> > > That left aside, most people surely still have no clue what "AppStream"
> > > is.
> > > 
> > > So it could make sense to have a small note mark to the right of the
> > > appstream:id link for the "What the heck is Appstream" use-case, so people
> > > could click/tap the button and learn about AppStream (or already learn a
> > > little in a tooltip, though a separate note mark still is needed for
> > > discovery and touch UI browsing).
> > 
> > About that: I wonder whether it would actually make more sense to show
> > a link like "Open in Software Center" or "Open in KDE Discover" or
> > anything more descriptive... AppStream is a rather technical term, and
> > if users need to read a page to know what it does, the links are less
> > useful.
> 
> The issue here is that we do not know what handler is invoked by the
> appstream: scheme. Only the browser knows. If lucky, it perhaps might be nice
> enough to show some information on cursor hovering (at least in a mouse-driven
> UI, no idea how touch UI can preview info about url handling on linked
> elements).
> Given the variety of names of the software installation managers on all the
> systems, I fear there is no generic enough name, which might not result again
> in people also thinking "Does not work for me" or wrongly thinking "Works for
> me".
> 
> IMHO the distro-agnostic appstream thing is an implementation detail and
> concept which can/should _not_ be hidden from the user here in the case of the
> distro-agnostic app pages. That would be trying to make things more simple
> than they are, and this will only result in more than less confusion.
> 
> So similar like flatpak or snap this is a concept which needs to be understood
> by those people who want to become independent of what is only available
> inside their distro's software manager. They have to know this is an appstream
> link to know if it is working for them (like they will have to know if flatpak
> or snaps work for them).
> 
> Everyone else, who is not smart enough to learn about appstream links, should
> not try to install something from the internet anyway, unless they also fancy
> shooting their parts of their own body ;)
> So IMHO the motivation for putting the name "AppStream" on the button images
> offered on
> https://www.freedesktop.org/software/appstream/docs/sect-AppStream-Services-UrlHandler.html \
> was correct, "AppStream" is a term/concept to be used here. 
> > > @Matthias: is there some distro-agnostic end-user website/page this "About
> > > AppStream" symbol could link to?
> > > Only found
> > > https://www.freedesktop.org/software/appstream/docs/chap-AppStream-About.
> > > html but that is not really consumable by Sue and Joe -No-Code-Please-
> > > User.
> > 
> > We could make one...
> > https://www.freedesktop.org/wiki/Distributions/AppStream/ exists, but
> > since AppStream is a rather technical project, I don't think we even
> > should attempt to explain it for users who will never see the metadata
> > (what is metadata anyway? - we'd even need to explain that first).
> > IMHO some short explanation maybe in form of a small "what is this?"
> > info on the webpage or a tooltip which shows something like "Open the
> > page of this application in the software center of your operating
> > system" would be much more useful. And since at time *every* software
> > center on Linux, including the one on Ubuntu, uses AppStream metadata
> > and appstream-IDs, we can simplify and generalize a lot :-)
> 
> Ah, what I meant was an explanation for just the appstream: link and what it
> is used for: that it is a distro-agnostic way to activate the software manager
> of one's operating system to try to install a version of that very software if
> available from a location trusted/used by that very software manager, by the
> means of that unique identifier for the software as used in the url.
> 
> No mentioning of any other metadata stuff, just this. I would assume a person
> who already learned what a link is should be able to get this.
> 
> This discussion makes me wonder if such links should not be having a different
> separate (marketing) name. That would allow to promote the concept of such
> links completely separate from the implementation detail of the distro-
> agnostic appstream metadata and all the other stuff it allows inside the world
> of software managers.
> 
> So to summarize:
> 
> Given this very use-case:
> Us upstream (source-code developers) wants to point the end-users to packages
> of our software provided by downstream (distributions). Either because
> upstream cannot provide such packages themselves or because the end-user only
> trusts their distribution.
> This needs to be doable in a distro-agnostic way. Also does it need to be
> processable by software, so end-users do not have to retype something and know
> where to retype this exactly.
> (So this is not about e.g. software manager internal communication, e.g. with
> web pages for the UI which talk back to the core by urls.)
> 
> Proposed solution:
> An url seems a good approach, with a dedicated scheme and the generic, distro-
> agnostic app identifier being encoded in the rest of the url, with the address
> space being inside the world of the respective software manager handling this.
> Such urls would work in web pages, but also other places like documentation or
> text-based communication (email, chat).
> 
> The appstream: urls are an existing scheme here and already supported by some
> software manager apps (which also install handlers for the scheme into the
> system).
> 
> Disadvantage of the term "Appstream" is that is also refers to the app
> metadata system in general, so end-users/developers searching for explanations
> will only be confused and useless discussions held (cmp. e.g. existing
> wikipedia page or similar docs about "AppStream").
> Also might it be not too descriptive for the given use-case, and Amazon
> occupying the term for something different but slightly related adds to the
> problem.
> 
> Thus a new dedicated name, both used in the url scheme and for marketing such
> urls, might be good. As user-facing appstream: urls have not yet appeared a
> lot in public places, there is still time for starting with a new specially
> designed name.
> AppStream metadata then would just be the implementation detail for this,
> providing one way to define the id that should be used by the software manager
> for resolving any incoming app urls as discussed here.
> Same like telephone uri, email uri, or geouri just point to an id, whose
> metadata is then resolved by the system processing the uri.
> 
> If we could rule the scheme world, this would be best, by example of Okteta:
> app:org.kde.okteta
> 
> It would perhaps even allow to use path?query#fragment for specifying a
> version and even action intends, e.g.
> 
> app:org.kde.okteta/0.23.0/?action=install
> 
> which could be used in release announcements to allow users to query their
> software managers by a simple mouse click if the new version is already
> available from the trusted/registered package stores.
> 
> Having such a separate non-appstream url should only need minimal adaption
> with the software manager apps, they only will need to also support the new
> scheme (additionally).
> 
> So what name to use? Ideally both the scheme and the technology should have
> the same name, so there is not a lot to know. Something based on english terms
> might help as well.
> It would need to be cross-desktop, cross-platform, cross-license.
> "app", "appid", "application" come to mind, but conflict with schemes in use
> or terms otherwise occupied.
> Global App id, universal app id, ... too tired now to pass some good proposals
> here, will do in a later post.
> 
> Meanwhile... What do you think?
> 
> Cheers
> Friedrich
> 

I think you're overcomplicating the issue. If you want, you can check
whether if it's running Linux, but then as soon as it's Linux I'd
assume an appstream client is present. Otherwise an error message will
pop up, I would also assume that whoever is running a system without
gnome-software/discover is the geeky kind of person who will be able
to figure it out. Or just install these applications because they're
there to be used.

About adding further information in the url, I think it's an error.
It's very hard to get it right and distributions package the software
however they want (i.e. version), including the version will only make
the software center complain when people use any of the distros that
don't update the software when it stops being supported by KDE. Just
finding an older version of the software is just fine. The action is
something impossible to implement (do we want to have
action=uninstall? action=update? how does the website figure these
out? Impossible).

I'd say: enjoy the appstream:/ urls, it's a simple albeit new
technology we can leverage now and we should undoubtedly. Other things
could be possible but this works and is already standardized and
implemented. I hope you can see the value in it like I do.

Aleix


[prev in list] [next in list] [prev in thread] [next in thread]