Didier Kryn said on Wed, 23 Jun 2021 00:00:11 +0200

>Le 22/06/2021 à 19:10, Steve Litt a écrit :
>> Didier Kryn said on Tue, 22 Jun 2021 18:00:17 +0200
>>
>>> Le 22/06/2021 à 14:20, Steve Litt a écrit :

>    Both Hopman-cli

Let's call it Hopman-Backend. It shouldn't have to do any user interface
work of any kind: Just implement an API or Domain Specific Language
(DSL). If somebody wants a CLI (Command Line Interface) front end to
it, that could be developed using ncurses, dmenu etc.

> and the GUI must read hopmanrc at startup (it seems
>simpler to have a single file to configure both).

I disagree with the single file. Tom wants to use a Python/Tk front
end. Dick wants to use a GTk front end. Harry wants to use a CLI front
end. Each of those front-ends should have its own config. If this is
structured right, the only thing the front end should need to know
about the back end is the filenames of any fifos, pipe files, etc.
Naturally, the API or DSL should be in a file available to the back end
and any front end.

> Possibly the name of
>the GUI application might be specified in hopmanrc and Hopman-cli would
>launch it.

That works for me. Or just put the front end as a command line arg to
the back end. One of them has to launch the other, unless we want a
process manager/supervisor to run the back end at boot.

>
>    Both applications must die immediately when the pipe is broken.

That sounds doable.

>
>    I don't think the GUI is a piece of cake, but you seem to have some
>experience (~:

Not really. The only thing is, the front end is just a front end that
interoperates with the API or DSL. My program would do nothing
complicated. I actually wrote something similar in 1986, command line
interface, on DOS, in order to interact with a VAX miles away. Worked
just fine. The VAX guys gave me the commands the VAX expected and the
responses it put out, and I just made the front end.

> Note that this a reactive program: it must react on
>input data available,

I assume you mean input data *from the backend* *to the front end* is
available. I can handle that with polling or by having the back end
throw a signal at the front end. If the back end forked the front end,
then the front end knows the PID to signal.

> mouse-click,

If I'm understanding correctly, reacting on mouse-click is what GUI
front ends do.

> and child-termination,

Which child?

> while
>periodically reading /proc/self/mounts.

Periodically reading /proc/self/mounts is something the back end would
do.


> I think the most difficult is
>to check the result of helpers and forward their messages to the user.

I'm not familiar with helpers.

The way I visualize it, when the back end has new data for the front
end, it writes that data to a pipe or file or whatever, and then
signals the front end (perhaps SIGUSR1). Once the front end has the
data, it's the front end's job to translate the raw data to something
easy to digest for the user.

>
>    If this seems too difficult, Hopman-cli could take care of mount
>helpers, but this would require a bidirectional communication, making
>it impossible to launch both applications from the command-line
>(Hopman-cli should be in charge of launching the GUI).

hopman-init hopman-backend my_hopman_frontend

hopman-init's whole purpose is to receive the PID of hopman-backend and
inform hopman-backend of its own PID. Hopman-backend then forks
my_hopman_frontend, so hopman-backend gets the PID of
my_hopman_frontend during the fork. Hopman-backend later informs
my_hopman_frontend of hopman-backend's PID as data. So each can signal
the other when there's data ready.

By the way, when I did something similar to the preceding paragraph,
some of my friends told me there's a better way than signalling data
ready with a signal. I forgot what they told me though.


SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques