>>3379
Зачем? Ты ебанутый?

>>3380
Что не так? Клиент имиджборд для десктопа вполне интересная вещь.

Но это спрашивал админ одной борды, он про мобильные говорил вроде.
> там просили мобильный клиент. Я за, сам давно думал, идея классная. Но я точно не буду писать с нуля функциональный клиент для ИБ. Единственное, что могу - написать плагин к существующему. Из +- подходящего для такого только dashchan, но он польностью под android, а я хочу кросплатформу. Так что пока без мобильного клиента.

>>3381
Что так? Каких возможностей веб-стека тебе не хватает, что аж QT нужен?

И мало того, что админ и так потенциально логгирует ВСЕ о твоем клиенте, так теперь и автор клиента заимеет ПОЛНЫЙ доступ к твоему компу (или где там работает твое QT-приложение). Если админ борды и автор клиента - это одно лицо, то вообще пиздец. Проще сразу скан паспорта ему присылать на почту.

Это не говоря уже о таких мелочах, как всякие браузерные плагины, куклоскрипты (я не юзаю, но вроде оно популярно), адблок чтоб скрывать кал, темные темы и т.д Все это в чудо-клиенте работать НЕ БУДЕТ.

Если ты подразумеваешь общий клиент (для нескольких борд) - то это получше вариант, но ставить на комп я бы все равно побоялся. Да и все равно, какая разница, если единого API нет, как иначе общаться (кроме HTML-интерфейса) - непонятно. Модули никто пилить не будет все равно.

>>3382
> теперь и автор клиента заимеет ПОЛНЫЙ доступ к твоему компу
Решается открытым кодом

> всякие браузерные плагины, куклоскрипты (я не юзаю, но вроде оно популярно), адблок чтоб скрывать кал, темные темы
Все фичи должны быть в клиенте

>>3383
> общий клиент (для нескольких борд)
Лучше так

> Да и все равно, какая разница, если единого API нет, как иначе общаться (кроме HTML-интерфейса) - непонятно.
Почему всем так больно парсить html?

Тут скорее проблема в том, что не принято делать приложения для десктопа. Есть 5 мобильных клиентов для имиджборд, а для десктопа ни одного. Потому в мобильных приложениях лучше изоляция и на мобилках принято пользоваться приложениями, а не браузером.

Что-нибудь по типу
https://woob.tech/modules#mod_phpbb

>>3384
> Решается открытым кодом
Чел, ну наивно же. Сто раз уже сказали. Вот я выложу на гитхаб открытый код, а в релизы положу client.exe с майнерами вшитыми. Кто узнает, что я его скомпилял из своей закрытой ветки, где у меня код с майнерами мержится?

Твой следующий шаг - ты сейчас расскажешь про reproducable builds, но никто этим по факту заниматься не будет. Как и читать твои исходники, и тем более компилять их вручную. И нейронки тоже запускать никто не будет, тоже не надо предлагать.

> Все фичи должны быть в клиенте
Да, как раз и получится огромный комбайн с исходниками на мегабайт, которые точно читать не будет никто, даже нейронка.

> Почему всем так больно парсить html?
Ну потому что он РАЗНЫЙ. Смысл не в формате, а в контракте (чтобы поля были одинаковыми, с теми же именами и структурой). Вот тогда будет легко сделать клиент. Но такого никогда не будет, в лучшем случае договорится 3-5 борд, но остальные-то все равно забьют.

JSON в этом плане немного проще, потому что это гораздо более простой и строгий формат. Поэтому зная контракт, сравнительно несложно сделать по нему клиент. Плюс JSON часто уже прям встроен в средства языка. Для HTML нужен целый XML-подобный парсер, а там куча мороки обычно.

Короче кривая это идея, что мы собственно и видим на практике (никто ее так и не реализовал).

>>3385
> Вот я выложу на гитхаб открытый код, а в релизы положу client.exe с майнерами вшитыми
Репутация + проверка мейнтейнерами основных дистрибутивов линукса. Это в долгосрочной перспективе.
Можно запускать в sandboxie под виндой и firejail под линуксом.
Ещё вариант - вынести поддержку конкретных сайтов и движков в простые модули, а основа клиента должен быть известной и доверенной. Как в этом woob.

> Ну потому что он РАЗНЫЙ
Один раз пишешь селектор и все работает вплоть до изменения генерации html движка. На некоторых бордах с готовым движком меняют html под себя - придется специально писать селекторы.

> Смысл не в формате, а в контракте
Именно json стандартизируется, а html нет.
Наверно, парсить html просто не принято и его парсер не встроен в большинство языков.

> Да, как раз и получится огромный комбайн с исходниками на мегабайт, которые точно читать не будет никто
Тогда надо разделять клиент на доверенную основу и модули.

Если в woob для phpbb модуль написали, то можно и для tinyib и vichan. Только никто почему-то не заинтересовался в создании модулей для них.

Впрочем, этот woob msg-qt как говно выглядит. Буквально программа из нулевых.
https://woob.tech/media/images/screenshots/msg-qt.png

>>3382
> Каких возможностей веб-стека тебе не хватает, что аж QT нужен?
Отвязка от браузера же

>>3387
> вынести поддержку конкретных сайтов и движков в простые модули
Все упирается в два варианта: либо у тебя будут модули со сторонним исполняемым кодом, либо это будет конфиг-разметка. В первом случае теряется безопасность, во втором - появляется требование жесткого контракта, который никто не будет соблюдать.

> все работает вплоть до изменения генерации html
Потом случается РЕДИЗАЙН, или еще какая хуйня, админчик завозит новые фичи, и вся разметка улетает в пизду. Еще прикол в том, что большинство админьчиков (и даже авторов движков!) не умеют писать HTML, хотя казалось бы. Попробуй например сделать селект даты поста в TinyIB - ты охуеешь: https://tinyib.rocket9labs.com/

> парсить html просто не принято
Его сильно сложнее парсить, а профитов в данном случае нет. Для правильного парсинга HTML нужна сложная и жирная внешняя XML-либа, и/или селекторный движок, и это не спасает от мудака, который напишет хуевую разметку.
В JSON таких проблем даже близко нет, его может парсить буквально стейт-машина, и все данные там есть сразу, даже с типизацией. Криво собранный JSON не парсится и сразу бросает ошибку, что тоже плюс. Опять же валидация по схеме проще во много раз.

---

Вообще я просто не вижу смысла во всей этой идее. Вот допустим сделали такую штуку. Что дальше? В идеале у тебя получился отдельный БРАУЗЕР, но для борд. Зачем тебе браузер, когда у тебя уже есть один? Вот без лозунгов и красивых слов, какая конечная цель? Чего добились конкретно?

И это, повторюсь, в идеале - на практике у тебя выйдет непонятное пердоподелие с поддержкой 2.5 борд, и все на этом.

Если уж думать на эту тему, то лучше начать с какого-то общего протокола на базе того же JSON, но по сути примерно как POP3/IMAP для почты.

>>3488
> во втором - появляется требование жесткого контракта, который никто не будет соблюдать.
Почему? Нормально определить формат конфига.

> Потом случается РЕДИЗАЙН, или еще какая хуйня, админчик завозит новые фичи, и вся разметка улетает в пизду.
Это редкость. Возможно оперативно обновлять.

> Попробуй например сделать селект даты поста в TinyIB - ты охуеешь
В теге label лежит, но не обернута в собственный в отличие от других метаданных поста. Легко можно спарсить.

> Вот допустим сделали такую штуку. Что дальше? В идеале у тебя получился отдельный БРАУЗЕР, но для борд. Зачем тебе браузер, когда у тебя уже есть один? Вот без лозунгов и красивых слов, какая конечная цель? Чего добились конкретно?
Если кратко - не будет прибит гвоздями сайт к блоатварному и жирному браузеру. Вот этого добились.

Разработка собственного браузера, не форка, движка для браузера с поддержкой всех современных веб технологий типа Blink или Gecko на уровне стоимости космической программы. Есть ladybird, но он совершенно не может конкурировать с ними. https://www.opennet.ru/opennews/art.shtml?num=57775
Отвязка своего сайта, да и в принципе любых сайтов в вебе от гигантской кучи веб стандартов и их багов, которые тянет обычный браузер, в принципе важная задача.

Ещё раз напишу про woob - Web outside of browsers. Он как раз про это.
Вот так они отвечают на вопрос "Что дальше?":
< Why use woob
< • You get information faster
< • You can script around woob to automate tasks
< • It extends websites features
< • It helps blind people use crappy websites
< • Reuse your favorite applications.

> в идеале - на практике у тебя выйдет непонятное пердоподелие с поддержкой 2.5 борд, и все на этом.
В идеале можно сделать модули woob для поддержки стандартных движков типа вичана и тинииб.

> Если уж думать на эту тему, то лучше начать с какого-то общего протокола на базе того же JSON, но по сути примерно как POP3/IMAP для почты.
Любой протокол децентрализованных соцсетей же. ActivityPub из федиверса вполне использовался в fchannel. Конечно, он там фигово реализован, из мастодона не запостишь. ActivityPub по сути и есть POP3/IMAP на базе JSON.

>>3497
Зачем "отвязывать веб от браузера", если для форумчиков можно просто сделать свой протокол типа векторного гипертекстового NNTPv3 лол

>>3497
> Легко можно спарсить.
Чувак, ты не понял видимо. Тебе надо:

1. Найти <label> внутри .op или .reply
2. Извлечь все его содержимое в виде текста
3. Извлечь подстроку по паттерну \d{2}/\d{2}/\d{2}\(\w{3}\)\d{2}:\d{2}:\d{2} (желательно с конца)
4. Спарсить как дату

Это без эдж-кейсов, если дата например в другом формате, или если твой парсер не поддерживает такой формат.
Это мы не учли время, затраченное на выработку решения по этому полю (я этим занимался ранее).
И не забывай, что это только одно поле, а их там минимум 5.

Для json тебе надо:

1. JSON.parse()
2. posts[i].timestamp

Все. Это принципиально разные уровни трудозатрат. Что тут обсуждать вообще.

> не будет прибит гвоздями сайт к блоатварному и жирному браузеру
Я еще раз уточняю: без лозунгов и красивых слов. "Жирный", "прибитый гвоздями", "важная задача" - это что такое? Конкретные результаты, метрики, кейсы есть у этого?

Смотри, вот пример проблемы и решения:

- Ситуация: ты вытираешь жопу пальцем
- Проблема: палец грязный, невкусно держать пузырек и пить бояру - воняет гавной
- Решение: достать бумажку и вытирать жопу ей
- Результат: гавной больше не воняет
- Метрика: раньше с трудом выпивался один пузырек. Сейчас выпивается 5-10, потому что не воняет

В твоей идее где такой паттерн можно увидеть?

> Вот так они отвечают на вопрос "Что дальше?"
Я читал их сайт - все равно не понял. Вот тезисно:

< • You get information faster
Типа сайты плохо грузятся? Или они на RSS намекают? Приделайте RSS к любому сайту - новости будут быстро появляться. (хотя в современном мире я уже об обратном думаю...)
< • You can script around woob to automate tasks
Всякие юзерскрипты лет 10 назад уже юзали.
< • It extends websites features
Какие конкретно фичес?
< • It helps blind people use crappy websites
Ну aria-атрибуты есть, я хуй его знает. Плохо подготовленное представление в любом случае будет crappy.
< • Reuse your favorite applications.
Именно то, что я делаю со своим браузером.

Короче, так и осталось неясным, зачем нужно отдельное приложение, которое точно так же лезет в интернет и получает там интернет-информацию в интернет-формате.

>>3517
> Все. Это принципиально разные уровни трудозатрат.
Один раз извлечь содержимое из такой кривой разметки, а следующие разы будет делаться аналогично.
Затрат больше, но не нечто нереальное. Тезис в том, что это возможно.

> Конкретные результаты, метрики, кейсы есть у этого?
Непосредственный контроль пользователя над работой сайта на его компьютере. Над тем что выполняется. Браузер выступает как черный ящик за счет своей раздутости - у пользователя нет контроля над ним. Как приятная добавка - снижение количества необходимой оперативной памяти, нагрузки процессора.

> Типа сайты плохо грузятся?
Жирные javascript фреймворки делают загрузку сайтов долгой, да и в принципе сама работа браузера.

> Всякие юзерскрипты лет 10 назад уже юзали.
Тут можно непосредственно из оболочки, а не внутри браузера запускать скрипты.

> Какие конкретно фичес?
То что конретное приложение woob реализует, но нет на самом сайте.