Если сюда тыцнуть, то всплывает окошко, куда свою урлу вбить можно.

Это фича протокола. Страница возвращает код 10 Input Expected, клиент в ответ спрашивает у пользователя и отправляет строку на тот же урл. BBS и Station так же работают.

Еще как-то RSS-feeds в gemini автопостятся, как я понял.

Фид - это специально сформированная страница в Gemtext со ссылками.

2024 год, а у них CGI и костыль на костыле.

CGI примитивен:

1. Информация о запросе в env переменных.
2. Тело HTTP POST запроса в STDIN.
3. STDOUT отдается браузеру.

Что более сложное вы предлогаете для Gemini? А главное зачем?

UPD: Сегодня я как раз на эту тему писал пост Ловушка новых технологий. Работает CGI и хорошо. Для данной задачи этой технологии хватет. CGI прост, понятен, надёжен. Подход 2024 год надо использовать язык не старше 3 лет - это прежде всего вредить себе.

натурально

git clone https://git.skyjake.fi/gemini/bubble.git

Или по хатэтэпээсу ВАм не кошерно?

ASGI / WSGI намного удобнее умирающих скриптов. И по производительности они недосягаемо впереди — пыху вон как не оптимизировали, а она всё равно проигрывает.

Банально, например, можно лёгкий кэш хранить прямо в массиве. А в CGI нужно костылестроение на каждом шагу.

Из живых есть jetforce, но он не поддерживает титан.

/me мимокрокодил и как мимокрокодил замечу, про вебню читаешь — каждый хак, фреймворк, язык, технология чего-то до ускоряет постоянно или сокращает нагрузку. А в результате всё только больше торомозит и жрёт ресурсов. Зогадка века!

И по производительности они недосягаемо впереди — пыху вон как не оптимизировали, а она всё равно проигрывает.

Подобные замеры прозиводительности выглядят так: одна машина по прямой едет 170 км/ч, а вторая 225 км/ч. На этом основании делается торжественный вывод, что первая машина безнадежно устарела.

ASGI / WSGI намного удобнее умирающих скриптов.

Это дополнительный слой абстракции для конкретного языка: ASGI для Python, Rack для Ruby. CGI просто для любого процесса в UNIX системе, вне зависимости от языка на котором он написан.

Пока у тебя полтора запроса в час, годится примерно все. И статический контент тебе кто угодно отдаст со страшной скоростью. А стопицот запросов в секунду, ala facebook и иже с ним, ты на одной стороне сервера не вытянешь, как ни старайся. Понятно, что такой нагрузки во всем gemini space и не предвидится, поэтому сервера там можно на чем угодно лабать.

Фид

Пришло уведомление, могу продемонстрировать.

# @Gentooshnik

## Notifications
=> /notif/234474 2024-10-07 💬 jecxjo replied in discussion about "What is your goto games on Linux? Does any of..."

=> ссылка дата текст...

Lagrange (и многие другие) такие страницы парсит как фиды. Если ссылка из фида исчезла, то она считается прочитанной. Бонусом, такую страницу можно просто браузером открыть. https://i.imgur.com/yVky5T3.png

ты на одной стороне сервера не вытянешь, как ни старайся.

Это вы к тому, что отдать всем одинаковую статику, а потом json малого размера для рендеренга на клиенте?

Классно! Сейчас зашел на gemini://bbs.geminispace.org:1965/s/LinuxGaming/20283 читаю.

Тормозит доменная логика. Запросы даже в медленном django обрабатываются за миллисекунды, но ведь в реальном проекте всегда 100 запросов к базе, дёргание внешних апи, обработка данных, десятки middleware для безопасности и разграничения прав доступа.

Как ни странно, именно поэтому важно ускорять фреймворки. Когда к тяжёлой логике добавляется ещё тяжёлый сервер — он становится совсем медленный и ложится под 1 юзером, который активно жмёт по ссылкам.

Подходы тоже нужно оптимизировать. CGI хорош для home page, но как только нужно сделать что-то посложнее — сразу начинается боль. От него ушли именно по той причине, что удобно горячие данные хранить в переменных, а не выдёргивать каждый раз из базы, обмазываясь синхронизациями и борясь с deadlock-ами.

но ведь в реальном проекте всегда 100 запросов к базе, дёргание внешних апи, обработка данных, десятки middleware для безопасности и разграничения прав доступа.

И WebSocket на каждый чих даже для односторонней коммуникации.

Пример:

import os
import subprocess
import sys
import urllib.parse

query = os.environ["QUERY_STRING"]
if not query:
    print("10 Enter your cowsay message: ")
    sys.exit()

text = urllib.parse.unquote(query)
try:
    proc = subprocess.run(
        ["/usr/local/bin/cowsay"],
        input=text,
        capture_output=True,
        check=True,
        text=True,
    )
except Exception:
    print("42 Unexpected Error")
else:
    print("20 text/plain")
    print(proc.stdout)

import subprocess

from jetforce import GeminiServer
from jetforce import JetforceApplication
from jetforce import Response
from jetforce import Status


app = JetforceApplication()


def _cowsay(text):
    try:
        proc = subprocess.run(
            ["/usr/local/bin/cowsay"],
            input=text,
            capture_output=True,
            check=True,
            text=True,
        )
        return proc.stdout
    except Exception as e:
        return e.message


@app.route("", strict_trailing_slash=False)
def index(request):
    if request.query:
        return Response(
            Status.SUCCESS,
            "text/plain",
            _cowsay(request.query[:256])
        )
    else:
        return Response(Status.INPUT, "Enter your message (max 256 characters)")


if __name__ == "__main__":
    server = GeminiServer(app)
    server.run()

Первый пример может показаться более удобным и лаконичным. Для простого cowsay это действительно так. Но добавим следующие задачи:

• сделать главную с результатами всех команд
• добавление записей вызывать отдельной ссылкой

И вот первый случай уже превращается в боль: нужно делать ещё один скрипт для главной, нужно писать тексты в файл или в базу. А во втором просто дописываем новый путь к декоратору у index, добавляем общий list и ещё одну функцию для его рендеринга.

Я тут уже упоминал bubble. Это типичный говнокод, где даже базовый паттерн MVC отсутствует — всё тупо намешано в одном файле. KISS и SOLID тоже идут нафиг. Я повидал много таких проектов — все они однажды становятся не поддерживаемые, потому что уже никто не в силах разобраться в тоннах говна.

А astrobotany, написанный по-современному, понятен сразу даже несмотря на недостаточную декомпозицию и несколько плохих решений (импортировать views.py в конце app.py — это треш лютый). Если что, у него тоже есть форум. Такой код легко сопровождать и оптимизировать (там местами есть горячий кэш, например).

Пока у тебя полтора запроса в час, годится примерно все

Попробуй написать чат для 2 человек и ты быстро поймёшь, что это не так.

потому что уже никто не в силах разобраться в тоннах говна.

Но на кой ляд в гемини поднимать хайскалабилити хайаваилабилити энтерпрайз продакшен платформу?)

Что не коммент, то удар молота загоняющий костыль в шпалу по шляпу. Коротко и ёмко. Хрясь.

Странная какая-то дихатомия современный - не современный. Важней понятный или не понятный код.

Первый пример не зависит ни от чего. Второму уже нужен jetforce, пошло поехло собирание библиотек для примитивного протокола.

или

print("20 text/plain")
print(proc.stdout)

или

       return Response(
            Status.SUCCESS,
            "text/plain",
            _cowsay(request.query[:256])
        )

Возникает вопрос где тут KISS?

Первый пример не зависит ни от чего

Тоже не осилил прочитать текст полностью, как пятизвёздочный выше? Ну-ка реализуй чат на CGI, без СУБД и файлов. У jetforce такой лежит в примерах.

Тащить СУБД и писать для неё обвязку — это значит «не зависит ни от чего», а микросервис на микрофреймворке — это энтерпрайз продакшн.

Прямо как в экспериментах Аша.

Второму уже нужен jetforce

А CGI скрипты у тебя чем запускаются? Шизофренией?

Тоже не осилил прочитать текст полностью, как пятизвёздочный выше?

Осилил, внимательно прочитал ваш код и письмо.

Ну-ка реализуй чат на CGI, без СУБД и файлов.

Цель написать понятный код, а не отказываться от чего-то для доказательства чего-то.

А CGI скрипты у тебя чем запускаются? Шизофренией?

Не надо так нервничать. Дело не в CGI скриптах, а в понятности кода. У вас предзятое отношение к этой технологии только потому, что она «старая» и «медленная». Если где-то можно написать простой код который читающий поймет с ходу, но там будет обращение к файлам или СУБД, это лучше чем запутанный код тянущий зависимости.

Jetforce это микрофреймворк. А CGI — это всего лишь разновидность веб-сервера. Кстати, он в нём тоже есть. Bubble использует похожий сервер, тоже на python.

Некоторые капсулы по 2 минуты грузятся. Наверное, это такой маркетинговый ход — чтобы отпугивать всех посетителей обратно в веб с его мерзими продакшн платформами, которые отдают контент за 10ms.

А CGI — это всего лишь разновидность веб-сервера

CGI это интерфейс для общения с процессом.

Я наглядно продемонстрировал, что даже в простом примере расширить функционал кратно затратнее, если архитектура CGI. Вроде как gemini про минимализм, но если надо оправдать ретроградство — то сойдут и лишние СУБД, и дедлоки, и красноглазие над всем этим добром. В данном контексте смешно читать про предвзятость.

простой код который читающий поймет с ходу, но там будет обращение к файлам или СУБД

Такое бывает только в манямирке. Всё ещё жду более понятный аналог чата на CGI, который бы хоть попытался доказать этот бред.

наглядно продемонстрировал, что даже в простом примере расширить функционал кратно затратнее, если архитектура CGI.

Вы продемонстировали простой и переусложденный код рисующий корову, с припиской, что переусложненный станет лучше когда надо будет добавлять расширения.

Всё ещё жду

Вам я не обещал писать какой-то код. Ждите.

манямирке… этот бред.

Слюни подотрите.

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

то сойдут и лишние СУБД, и дедлоки,

SQLite это не лишняя DB, а удобный способ не возиться с файлами, а пользоваться SQL запросами. Конечно если следовать вашей концепции и тянуть какую-то тяжелую СУБД на будущее то да, будет лишняя база данных.

Теперь про дедлоки. Честно говоря тудно смоделировать реально возможную ситуацию в протоколе Gemini когда два процесса одновременно будут требовать доступа к ресурсам занятым друг другом и на этом все остановится. Один не может продолжать пока не получит реурс второго, второй пока не получит ресурс первого.

100 запросов к базе, дёргание внешних апи, обработка данных, десятки middleware для безопасности и разграничения прав доступа.

Полагаю это именно та причина, отчего кому-то захотелось выкинуть всю эту бодягу на мороз и взять что-то по-проще.

Ну-ка реализуй чат на CGI, без СУБД и файлов.

А потом вы предложите онлайн банк и трейдинговую площадку на gemini нарисовать? Вам специально сделали ограниченный протокол, для ограниченных задач. Это не вызов, чтобы нарочно всё усложнить. Для этого обычный веб имеется. Если вам кровь из носу нужен чат, возьмите irc, а лучше jabber. Они работают в миллион раз лучше вебни, быстрее и проще.

тудно смоделировать реально возможную ситуацию в протоколе Gemini когда два процесса одновременно будут требовать доступа к ресурсам занятым друг другом

У веб-сервера может быть больше чем 1 обработчик и CGI скрипт будет вызываться ими одновременно, дабы обработать параллельные запросы. Это может случится даже в одном обработчике, если он асинхронный. Зависит от реализации конкретного сервера.

Именно по этой причине SQLite редко используют в CGI архитектуре — в нём возможны взаимные блокировки при записи. Он быстр и оптимизирован, но всё же.

А вот в ASGI — запросто. Причём, внезапно, обработчик ASGI эффективнее обработчика CGI, потому что:

• Скрипты не перезагружаются, а значит и нет накладных расходов на инициализацию и создание нового подключения к СУБД.
• Можно использовать горячий кэш.
• Можно писать асинхронную логику, которая обрабатывает сразу множество запросов.

В gemini есть новостные агрегаторы. Это сразу 3 действия:

1. обходить ссылки по расписанию (писать в базу)
2. отдавать контент (читать из базы)
3. добавлять новые ссылки от пользователей (писать в базу)

При CGI точно будет deadlock, если использовать SQLite. Потому что как минимум два из этих пункта не могут происходить в рамках одного обработчика (ну, если не отключать отдачу контента на время обхода, что тупость). Но в ASGI архитектуре достаточно вынести краулер в отдельный процесс, который будет отправлять собранный контент на сервер обычным запросом на локалхост (у gemini нет post, но можно сохранять в файл, а сервер будет его по запросу вычитывать), где он уже синхронно будет сохраняться в SQLite базу, а пользователи смогут его оттуда читать.

SQLite достаточно быстрая штука, его хватает на сотни тысяч запросов в секунду. Но из-за CGI приходится тащить MariaDB / PostgreSQL. И где же тут минимализм, а?

Bubble требует MariaDB, потому что там CGI. Astrobotany спокойно использует peewee и SQLite. Второе лучше чем первое не только по качеству кода, но и по экономии ресурсов и удобству администрирования.

В первом, к тому же, нет ORM, вместо него чистый SQL. Что дальше — будут утверждения, что sql injection не баг, а фича? ORM это же сложна сложна нипанятна, зачем это в таком простом gemini, пусть лучше будет sql injection.

Собственно, всё. На этом я сливаюсь, ибо ну совсем детский сад, который положено знать даже трейни, а я тут не халявный ментор.

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

У веб-сервера может быть больше чем 1 обработчик и CGI скрипт будет вызываться ими одновременно, дабы обработать параллельные запросы.

Не надо запускать CGI скрипты паралельно, там где надо запускать что-то паралельно, нужно выбирать другие инструменты.

Собственно, всё. На этом я сливаюсь, ибо ну совсем детский сад, который положено знать даже трейни, а я тут не халявный ментор.

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

… и прийти к тому же самому. Юзеры, пользовательский контент, права доступа, модерация, внешние интеграции. Эволюционный путь фреймворков точно такой же, как в вебе, о чём я тут и пытался донести. На кой чёрт полностью его повторять, если можно сразу сделать как надо? Собственно, некоторые фреймворки и сделали. Но они сырые и полузаброшенные.

Я всё ещё не понял в чём проблема. Текущие серверные реализации не устраивают? Использование CGI нигде в спеках не прописано.

… и прийти к тому же самому. Юзеры, пользовательский контент, права доступа, модерация, внешние интеграции.

Смысл протокола Gemini не повторять путь HTTP, это написано прямым тектом в документации. Первое что вы начали делать это стараться вылепить из Gemini второй HTTP.

Эволюционный путь фреймворков точно такой же, как в вебе, о чём я тут и пытался донести.

Вы пытались донести то, от чего пытается уйти Gemini протокол.

Парень нам доносит как в Gemini сделать многопоточный сервер обрабатывающий 1000 запросов в секунду. Благодетельствует. Менторит.

Вот честно. На велоплощадку приходит идиот, который начинает рассказывать как надо усилить арматурой раму велосипеда, чтоб повешать на нее 200кг двигатель на 60 лошадинных сил. Ругает велосипеды технологией 19 века, и объясняет всем, что по трассе из Уфы в Киров будет долго ехать на велосипеде, по этому надо тут подварить раму 4 арматуринами, и сделать бензобак из ведра.

Картинку про троллейбус из хлеба видели? Вот, так веб в современное дерьмище и превратился. Взяли технологию, придуманную странички с текстом и картинками показывать и начали усложнять, пока не получилась виртуальная машина, в которой можно запустить свою ОС (почти), с иксами и браузером. Скоро на второй круг пойдут.

Я сдаюсь.

Может это Игорь Негода? https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://m.youtube.com/watch%3Fv%3DNbEEZT9MhUU&ved=2ahUKEwjm8LmA6vyIAxUkVfEDHXwnGHoQwqsBegQIDRAG&usg=AOvVaw2y9VJGAZvUlZYRplEnJpbk

Обещали минимализм, а на деле 100500 костылей и грабли на каждом шагу, если хочешь написать свой сайт чуть сложнее визитки.

Не тот дистрибутив

Не так обновился

Не те конфиги

Не то ядро

Не та видюха

Не тот проц

Не те руки (и не оттуда)

А разработчики молодцы, респект этим ребятам, которые третий десяток лет делают лучшее … Делают и делают, и делают, и делают, сука, и делают.

(c)

Да, приходится на велосипед наварить столько железа, чтоб прикрутить к нему двигатель от грузовика. Одни костыли. Что эти велосипеды такие хлипкие делают?

если хочешь написать свой сайт чуть сложнее визитки.

В Gemini нет сайтов, в Gemini капсулы. Gemini это прежде всего библиотека документов с перекресными ссылками, а не интерактивные приложения.

Если вы хотите писать сайт, берите HTTP.

А какое отношение протокол имеет к серверной архитектуре? Ну как бы да, во времена web 1 тоже были странички с одной кнопкой. Но эта кнопка вызывала энтерпрайз махину с гигабайтами исходников.

Вот объясни мне как трёхлетнему. Зачем писать условный rss агрегатор / поисковик / блог / форум (их несколько в gemini), используя заведомо плохую архитектуру? Чтобы что? Разве это не то самое усложнение?

Может это Игорь Негода?

Однозначно нет. Игорь Негода - гениальный инженер авиатор. Он реактивные двигатели скотчем к мопеду не привязывает, чтоб тот поехал быстрей.

Показывайте где в спеках костыли и грабли.

UPD: Или всё же текущие реализации этих спеков не устраивают?

используя заведомо плохую архитектуру?

Она не плохая, она простая и достаточная под поставленную задачу. Как в примере с коровой, код понятен и достаточен для переноса потока из процесса в ответ серверу.

А вот то что вы нагородили «на вырост», это пример плохой, перусложненной архитектуры.

Участвуя в сегодняшем споре становится очевидно, что протокол Gemini ждут постоянные «расширения» и «улучшения». И в конечном итоге появтися версия Gemini Enterprise Edition c возможностью запуска скриптов на стороне клиента.

На чужой gitok не накинешь платок.

Самое смешное (и грустное) что как раз вы бы смогли извлечь из Gemini наибольшую пользу, потому как вы и нуждаетесь более всего во внешнем ограничителе. Но, если бы вы это понимали, вам бы и Gemini не понадобился. Такой вот парадокс.

А вот то что вы нагородили «на вырост», это пример плохой, перусложненной архитектуры.

Некоторым инженерам просто нужно пройти через этот этап. К сожалению, многие на нём застревают.

Некоторым инженерам просто нужно пройти через этот этап. К сожалению, многие на нём застревают.

После сегодняшнего интесивного общения мне все больше нравиться Gopher. Что к нему улучшатели руки тянуть точно не будут, за все отдуется Gemini. Уже утяжелили Gemini этим титаном - нафиг не нужным. Понеслось строительство нового HTTP.

UPD: titan это отдельный протокол. https://lists.sr.ht/~adnano/gemini/%3C20200613053926.GH11281%40brevard.conman.org%3E

Anyway, it’s another protocol, very similar to Gemini but one that uses a new URL scheme, to ensure that no one mistakes this for the actual Gemini protocol.

Lagrange 1.18 и 1.18.1 (комментарий)

спеки != сервер

Со спеками всё хорошо.