Roy, Yes, I totally agree. I'd like to do something like you're suggesting but without having a fork or use a heavily patched version of hostapd. I'm sure there are people out there that are interacting on that socket with their own applications. For backwards compatibility, it would make more sense to create yet another socket interface that does what you're suggesting and give people a few versions to move off that onto the newer interface. Thanks Jake -----Original Message----- From: Roy Marples <roy@xxxxxxxxxxxx> Sent: Sunday, November 10, 2019 12:28 PM To: Gladish, Jacob <Jacob_Gladish@xxxxxxxxxxxxxxxxx>; Andrej Shadura <andrew@xxxxxxxxxx>; Teunis Peters <teunis.peters@xxxxxx> Cc: hostap@xxxxxxxxxxxxxxxxxxx Subject: Re: [EXTERNAL] Re: socket interface On 01/11/2019 17:26, Gladish, Jacob wrote: > I think dbus is pretty nice, but there are environments that won't run dbus. I'd propose that there would be one command/control interface and that the CLI would just be a client of that interface. If that's dbus, then fine, but something that didn't require another framework and just relied on libc would be better. So you want something in libc that's portable to all environments and that the CLI is just a client of that interface? What exactly is your issue with the socket interface that already exists? Sounds like it meets your needs perfectly. I think your beef is not with the socket itself, but the design of the interaction on it. Nothing stops you from creating a structure styled like route(4) from BSD where each message has a common header type and then you just unroll the structure matching the message from the receive buffer. Boom, you now are dealing with objects rather than strings. Roy _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
