> wpa_supplicant? прибитое гвоздями к своему wpa_cli, и подрехтованное под dbus?Там четкое разделение на backend и frontend. Можно собрать только backend без wpa_cli и настраивать через конфиг или wpa_gui.
> А как
> мне на телефоне скрипт сделать который в зависимости от названия AP,
> к которой прицеплен, всякие штуки делал? (Вопрос риторический, с намеком на
> неидеальность wpa как примера, особенно во встраиваемых вариантах.)
Тем не менее ответ на него есть:
https://wiki.archlinux.org/index.php/WPA_supplicant#wpa_cli_...
>> А как мне на этой гибкой технологии сделать классическое (без разделения клиент-сервер) приложение?
> #include <stdio.h>
> int main(int argc, char **argv)
> {
> printf("hello, i'm classic programm\n");
> return 0;
> }
Не вижу здесь gui на html5.
>> Что-то запрещает строить приложение как fronted-backend при использовании qt/gtk/etc?
> Лень.
> Лично мне лень познавать гтк, чтобы понять как отправить какому-нибудь демону команду
> что-то сделать, вычлиняя это из исходников клинта на gtk.
1. Обычно в таких случаях есть четко описанный api или протокол.
2. А вам не лень разбирать какие запросы происходят между браузером и сервером приложения? Особенно учитывая тот факт, что формально webapps не имеют четкого разделения на frontend и backend, и запросы могут меняться даже при минорном обновлении.
> Разрабам лень делать внятные инструкции или хотябы экзамплы чтобы это можно было
> не напрягаясь посмотреть.
http://w1.fi/wpa_supplicant/devel/
http://w1.fi/wpa_supplicant/devel/hostapd_ctrl_iface_page.html
wpa_supplicant-2.5.tar.xz/wpa_supplicant-2.5/wpa_supplicant/examples
Чего вам не хватает?
> Проблема, ИМХО, в отсутсвии внятного и человеческого межпроцессорного взаимодействия,
> поэтому одни еб..ся с dbus, которое перегруженно всякой хренью и гвоздями
> к ней прибито,
dbus я тоже не люблю.
> другие используют костыли предоставляемые из каробки всякими gtk/qt,
> хотя это ни разу не их задача,
В большинстве случаев (при frontend/backend) строится движок, независящий от gtk/qt. Например gimp, изначальный прародитель gtk, не являющийся формально frontend/backend, позволяет использовать его библиотеки и создавать новые графические редакторы не линкуясь с gtk совсем.
> а третьи лепят из
> того, что есть и http тут очень удачно подменяет IPC.
http может быть оправдан только при необходимости удаленного доступа. Для локального большой overhead, тормоза и расход памяти.
Для большинства приложений разнесение на frontend и backend не имеет большого смысла.
> У Бернштейна есть "эталонная" реализация tcp сервера, там кода строк 200, почему
> нет реализации простенькой IPC, которая как раз и будет слушать сокет
> хоть tcp, хоть unix, лично я не понимаю.
А в чем проблема слушать сокет? Можно nc использовать. Я для локальной сетки использую "busybox nc -ll -p 7777 -e sftp-server", в том числе и на телефоне.
Вот пример на d, тут фактически простой http сервер:
import std.socket, std.string;
void main() {
Socket listener = new TcpSocket;
assert(listener.isAlive);
listener.bind(new InternetAddress(8080));
listener.listen(10);
string webpage = "<html><body>hi</body></html>";
Socket currSock;
uint bytesRead;
ubyte buff[1];
while(1) {
currSock = listener.accept();
if ((bytesRead = currSock.receive(buff)) > 0) {
currSock.sendTo(webpage);
}
currSock.close();
buff.clear();
}
}
