Let's talk stdio!

[martinhpedersen]

Hi,

The gensio library looks like a very interesting and promising project. Although we haven't had much communication up until now, I've followed your Pat fork with great interest. The idea of having such a flexible and portable user-land AX.25+++ implementation is very tempting.

As previously stated, my main concern is the complexity of taking in such a large dependency chain in Pat. So a couple of days ago (in the shower of all places), it occured to me that this often is solved using micro services in backends. And in UNIX, the tradition is to build smaller composable apps talking to each other through pipes and sockets.

So how about if we could add gensio to the mix as a separate app which can be spawned by the host application, and communicate over stdio? Sort of like a netcat - a geniocat if you'd like 🤓.

The primary benefits would be to have independent release cycles and build systems for the two projects, much like we have with ARDOP and other soft modems. But still, from a user perspective it would be (mostly) transpartent as Pat would be able to spawn gensiocat under the hood when needed. All the user would need to do is to install the two separate apps.

Also, I'd imagine gensiocat would be useful in many other applications and a very good alternative to ax25-apps's call and listen.

We could talk raw stdio, or we could add a layer of AGWPE or similar to multiplex several connections. I guess the latter would be a good fit for AX.25, supporting simultaneous listen and connect(s) over the same KISS tty device.

Please let me know what you think of such an approach. Thank you!

[cminyard]

On Wed, Aug 24, 2022 at 11:44:30AM -0700, Martin Hebnes Pedersen wrote: Hi, The gensio library looks like a very interesting and promising project. Although we haven't had much communication up until now, I've followed your [Pat fork](https://github.com/cminyard/pat) with great interest. The idea of having such a flexible and portable user-land AX.25+++ implementation is very tempting. As [previously stated](la5nta/wl2k-go#56 (comment)), my main concern is the complexity of taking in such a large dependency chain in Pat. So a couple of days ago (in the shower of all places), it occured to me that this often is solved using micro services in backends. And in UNIX, the tradition is to build smaller composable apps talking to each other through pipes and sockets.

Most of my best ideas come in the shower :).

So how about if we could add gensio to the mix as a separate app which can be spawned by the host application, and communicate over stdio? Sort of like a netcat - a `geniocat` if you'd like 🤓.

It already exists, it's called gensiot, it was getting long enough that I didn't want to add the extra "ca" :). I've done BBS and point-to-point connections with it before. It should work, but you will lose packetization (which probably won't matter for this app) and the heard list if you use stdio.

The primary benefits would be to have independent release cycles and build systems for the two projects, much like we have with ARDOP and other soft modems. But still, from a user perspective it would be (mostly) transpartent as Pat would be able to spawn gensiocat under the hood when needed. All the user would need to do is to install the two separate apps. Also, I'd imagine `gensiocat` would be useful in many other applications and a very good alternative to ax25-apps's `call` and `listen`. We could talk raw stdio, or we could add a layer of AGWPE or similar to multiplex several connections. I guess the latter would be a good fit for AX.25, supporting simultaneous listen and connect(s) over the same KISS tty device.

I know direwolf and soundmodem support multiple connected devices, so with those you can have multiple listeners and connections at the same time. They will need different call signs for each connection, but they would need that, anyway.

Please let me know what you think of such an approach. Thank you!

It should work, not sure if it's the best solution. AGWPE is actually not a very simple protocol, though certainly simpler than implementing AX.25. And the protocol engineer in me is disturbed by the design. If we went that way, I know that soundmodem and direwolf already have it built in, so you really don't need the gensio stack. But you would lose the ability to talk to serial port TNCs (though direwolf might do that, not sure). That's actually, probably a big deal as I already have people using TNCs. I have toyed with implementing AGWPE, and it is doable. It would be easy to design a much simpler protocol. My basic goal for this was simplicity. The Linux AX.25 stack was just too hard for some of the hams here to figure out how to set up, and it's too frail. And buggy. My secondary goal was running on platforms besides Linux. I use a chromebook and would really like to run it there. Having another program in the stack that had to be running for this to work is not moving towards my goals. Running it over stdio is better, but I'm not sure it really decouples the two pieces of software that much. I really like just having one executable that the user has to run. (Well, two with the modem.) So I'm not sure. You are in charge, of course, and I don't want to maintain a fork, as that's no good for anyone. I think my preference would be something like I've already done. I understand you not wanting to have too much other software you are coupled to, but this has a standard go interface that is versioned. So it shouldn't be much different than any other piece of go software.

…

-corey - AE5KM

-- Reply to this email directly or view it on GitHub: #46 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[cminyard]

I think that AGWPE is the chosen path here, so I'm going to go ahead and close this.