Re: poke, hyperlinks, modeline, etc

[Jose E. Marchesi]

>> 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'.

That sounds very complicated to me for no good reason, and actually
potentially more insecure (and error prone) than the original proposal.
Temporary files mean a directory where to put them and to deal with
permissions, partitions, concurrent access to files, kernels being anal
(SElinux, etc), distro settings, and a large etc.  All that to associate
a file name suffix to a MIME type so we can execute app-client, which we
could execute directly?  Only thinking about implementing it well kills
me of boredom and apprehension.

We have a protocol that works for us.  It is simple, it does exactly
what we want, and it seems to work well, not requiring more than a
socket.

If the XDG people are completely closed to the idea of a new protocol,
and considering that what we want is precisely to use a new protocol,
then maybe they are not the right people to talk to, and XDG not the
right framework to work with?

I'm not trying to be difficult here, but really I don't understand why
would we use files, and MIME and what not for implementing something
that clearly doesn't have anything to do with files or MIME.

That said, I have to admit I have not a clear idea of what the XDG
people do since I don't use graphical environments or "desktops", so
maybe I am just babbling nonsense here.  (I do it often 8-)).

> This redesign also needs to address the security issues.
>
> This will need time, however. We can't finish this until next week.

Yeah, not for 1.0 for sure.

> 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.

Sounds good.

I would put app-client.c in poke/poke/.  The instructions would
belong... to a section in the user manual I guess?

Where can I find the latest version of app-client.c?  Do you have an
"upstream" repo or you would rather maintain it in poke.git?