poke-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: poke, hyperlinks, modeline, etc


From: Bruno Haible
Subject: Re: poke, hyperlinks, modeline, etc
Date: Sat, 20 Feb 2021 22:48:40 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-201-generic; KDE/5.18.0; x86_64; ; )

Hi José,

> This is what we envisioned when you introduced the terminal hyperlinks
> to us in one of the rabbit herd weekends, is really a new paradigm in
> interacting with command-line interfaces, and we now have everything we
> need to make poke use its full potential.
> 
> I am very excited about it.
> 
> However, this all depends on:
> 
> a) the app:// protocol we designed
> b) the little app-client utility that you wrote
> c) Having the different terminals configured to use (or to implement
>    themselves) app-client.
> 
> Your past attempt to get this somehow standardized with the XDG people
> wasn't successful, and the original author of terminal hyperlinks
> explicitly said he doesn't want to be involved with them any longer.
> 
> But when poke gets packaged in Debian, for example, we want hyperlinks
> to work for the Debian user.  Same for other distros.
> 
> What would be needed for that to happen?
> I would say:
> 
> 1) To go ahead and use app:// anyway.  Let's just ignore XDG and other
>    standardization boards/groups.  A good old de-facto standard works
>    just as well.
> 
> 2) To release app-client on its own.  A release tarball that distros
>    could easily package.
> 
> 3) To add app-client as an explicitly (optional) dependency of poke.
> 
> 4) To ask whatever distro packaging poke to also package app-client, and
>    to configure their terminal packages to use it when they see app://
>    hyperlinks.
> 
> WDYT?

My conversation with the XDG people (including Egmont) had the following
results:

  - They highlighted security issues with our current app:// protocol.
  - They disliked the idea of a new protocol. So we are stuck with files
    and MIME types.

My current thinking is (and sorry that I haven't pushed through on it yet):

We need a redesign, that uses a temporary file for each hyperlink that is
on the screen. Sounds inefficient, and it would be inefficient if we would
still work with floppy-disks. Many programs nowadays (e.g. browsers) change
dozens of files per second, depending on user interactions.

The suffix of the temporary file is then connected, through the MIME type
registry that every user can customize, to a program equivalent to our
'app-client'.

This redesign also needs to address the security issues.

This will need time, however. We can't finish this until next week.

For poke 1.0, we therefore need to stay with app-client. Since app-client
is scheduled to be replaced by something else soon, I would just bundle
app-client in poke, and have it installed through 'make install', and
document what is needed in order to make it work.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]