Jdavabrav — экскременты, образно говоря. Потому что он использует Qt webkit и requests. Про requests могу ошибаться, может быть я документацию не дочитал. И про qt webkit аналогично.
Я исправил баг с ютубом, оказалось он слал POST-операции в виде JSON. Офигеть, не так ли? То берут файлы и смешивают с текстом, разделяя через boundary, то просто строку типа var0=val0&var1=val1&..., теперь JSON. Я не разбираюсь в POST-операциях, надеюсь вы мне не скинете ещё какой формат.
В кьютешном вебките мне не нравится то, что он мне шлёт сырые данные, которые следует отправить в POST-операцию вместо значений переменных и открытых/названий файлов. Я бы и не против, но requests не хочет принимать сырые данные, он хочет сам собирать. В requests это и плохо, мало ли что он в boundary шлёт, пользователь не узнает. Может он через него айпи-адрес сливает. Может стоит перейти на urllib3, если оно будет поддерживать сырые данные, но я искал в коде как реализована POST-операция и не нашёл проверку на класс bytes. Как и в requsts.
Обновление пока не выйдет, потом выпущу.
Ютубовское видео тоже не загружается, не хочет ютуб давать мне, но на это почти наплевать, так как Jdavabrav позволяет открыть ссылку через тот же mpv или любую вашу любимую программу для просмотра видео.
В тор-браузере мне не нравится то, что он насильно переводит фокус в окне загрузки. Я запретил автоперевод фокуса на новые окна, у меня компьютер слабый. Я запускаю GUI-шную программу за 10 секунд до начала её использования, а в это время занимаюсь неравновременными делами. Пишу я текст и тут окно открывает и несколько букв съело. Ну как так можно?
Вообще ноги растут из древности, когда люди не знали что такое интернет, не было джаваскрипта, а закрытые программы являлись нормой, не исключая нормальность свободного и просто открытого софта.
Я же хочу сделать свой WEB, исправляющий множество проблем — приватности, производительности и хорошести. Он будет состоять из двух частей — сетевой и HMLной (hypertext markdown language). Сетевая имеет GET и POST операции, всё. При этом GET может получать GUIшную часть (HML), APIшную и документацию к API, которая тоже будет GUIшной. А POST только APIшный. При этом всякие IP это вторично, первично — общение с сервером, а под сервером может выступать и MCU, подключенный через переходник USB-UART без всяких обычных сетей.
Как я уже писал на лолифоксе, мой HML тоже будет иметь скрипты, потому что без них нельзя делать комплексный и сложный GUI. А точнее не скрипты, а программы. Программы могут быть написаны на разных ЯП, но по-умолчанию будет поддерживаться надстройка над laisi, не позволяющая взаимодействовать с ОС напрямую. Хотя позволяя иметь доступ ко всей памяти, которую даёт ОС, что может быть уязвимо на всяких x86-64. Благодаря тому что laisi может быть очень хорошо распараллелен, возможно делать WEB-игры или WEB-майнеры работающие так же хорошо, как если бы они были нативными программами, используя все GPU, TPU, NPU, SIMD и дополнительные процессорные инструкции и кластеризованные компьютеры.
Если рассмотреть саму MLную часть моего HML, то он поддерживает ссылки наложенные на текст или картинки, но при этом без скриптов они загружаться не будут, это лишь ссылка. Это минус, так как серверу придётся генерировать превью, но плюс, так как не будут загружаться чужие сервисы по сбору данных.
У веб-страниц моего веба было бы хорошо быть значки условий:
0. Программозный (Скриптозный?) — не может быть нормально использован без включения исполнения программы. (Интерактивные игры, например)
1. Безпрограммный — нет программ. (Документы и статьи)
2. Программы не влияют на возможность получения контента. (Кнопочки перестали мигать или счётчик какой-нибудь остановился, например)
3. Безкоммуникабельный — Если и есть скрипты, то дополнительные коммуникации не нужны. (несетевые, но интерактивные игры)
Это можно четвёртым типом запроса GET сделать.