Proposal for an intent-apps spec

[Thomas Kluyver]

On Thu, 6 May 2021, at 10:36, David Faure wrote:
> OK, I added "In any case it should be consistent across runs rather than 
> random (e.g. based on the order of an unsorted list of files from a 
> directory)".

Sounds good, thanks!

> > I'm not sure about the last sentence you've now added:
> > 
> > "A similar algorithm, apart from stopping at the first success, can be used
> > to list all available implementations of the intent."
> > 
> > I don't think it can, because, there's no reason to think that a given
> > implementation is listed in any intentapps.list file. 
> 
> Right. I should say:
> 
> "Similarly, those intentapps.list files, parsed in the same order, can also be 
> used to sort all available implementations by preference."
> 
> How does that sound?

Better, but I think it still implies that reading all intentapps.list files is sufficient to find all implementations of a given intent. I would say something like:

"It's also possible to put several implementations of an intent in order of preference by reading all intentapps.list files in the order above. But these files cannot be used to find all implementations of an intent; the desktop files are the canonical source of that information."
 
> > It would be possible to build a cache like mimeinfo.cache, but that's a
> > separate concern from selecting the preferred application.
> 
> And that can be implementation-specific (in KDE we already have such a cache, 
> called ksycoca, and IIRC mimeinfo.cache is glib-specific). There are benefits 
> to sharing caches, but let's not make that a requirement at this point :-)

I think mimeinfo.cache is meant to be shared - it's created by a standalone update-desktop-database command which is maintained under xdg (desktop-file-utils repo). But I agree that there's no need to detail caching in the spec at this point.

Best wishes,
Thomas