Comments 19
Бог ты мой... 180 тысяч строк кода на консольную обёртку над http get! И ещё внешние зависимости (9 штук, из которых 6 прямых). "А ведь этот ещё из лучших" ©
Курл это не только хттп, это очень много разных протоколов работающих под одним интерфейсом. Ну и наверное его древность тут играет роль, когда они начинали думаю 90% современных инструментов просто не существовало еще.
из неожиданного - есть поддержка SMTP https://everything.curl.dev/usingcurl/smtp.html
А еще можно кинуть запрос в RabbitMQ, чтобы убедиться, что он хотя бы живой
Более того, я считаю, что curlib - самый простой способ для работы с POP3 и SMTP что под виндами, что под линуксом. С IMAP, кстати, тоже работает, но я не пробовал.
Вот оттого, что программисты тащат в свои программы 180000 строк кода ради того, чтобы кинуть несколько текстовых команд в сокет, всё и работает так, как работает.
Кинуть несколько текстовых команд
Вы же в курсе, что вот прямо сейчас когда вы это своё сообщение написали и нажали "отправить", байтики потекли по бинарному протоколу, да?
Какое отношение это имеет к обсуждаемой теме?
curlib - самый простой способ для работы с POP3 и SMTP что под виндами, что под линуксом.
Какая разница, по большому счёту?
Письмо по SMTP можно голыми руками отправить с помощью телнета.
Какое отношение это имеет к обсуждаемой теме?
Прямое)
curl нужно поддерживать весь http со всеми переключениями, вариантами ответа, прозрачными для вызывающего пользователя / кода приколами, корнеркейсами и экзотическими сценариями.
В том числе, придётся поддерживать http/2
Так строчечки и набираются.
Письмо по SMTP можно голыми руками отправить с помощью телнета.
Можно. И по http/1.1 можно через telnet сходить. С некоторыми нюансами.
Откуда набираются строчечки в curl, я прекрасно понимаю. Мою критику вызывает то, что всю эту поддержку экзотических сценариев тянут в свои программы все, кому не лень, когда достаточно одного EHLO.
Ну, в случае необходимости отправить только EHLO, допустим.
Но какая ценность в общем случае в том, чтобы писать без наличия какой-то специфической фишечки свою реализацию клиента или сервера того или иного протокола?
(Не конкретному разработчику на правах личной ценности и развлечения - конкретному разработчику - дай волю, всё подряд будет с нуля писать и оптимизировать - а ценность именно что с точки зрения разработки чего-то)
В общем случае, если вы libcurl или аналог отберёте, вы не получите эксперта, прочитавшего нужный RFC в каждой команде, где протокол понадобится. Не получте и набора элегантных реализаций нужного для каждой конкретной задачи подмножества протокола.
Вы получите десяток говнореализаций, которые работают на честном слове и каждая из которых на самом деле нужному RFC не следует.
Нафига?
есть поддержка SMTP
Хм... Закон Завински: Любая программа стремится расширяться до тех пор, пока не научится отправлять электронную почту. Те программы, которые нельзя расширить, заменяются теми, которые расширить можно.
Замечательные утилита и библиотека. Широта охвата протоколов и платформ впечатляет, как и соотношение функциональность/объём. Пробовал curl под DOS - даже там он позволяет утилизировать гигабитный сетевой интерфейс практически полностью.
Спасибо автору и всем приложившим руку к curl, отдельное спасибо за перевод.
Объясните мне, кто в этом разбирается, почему именно голый Си древних версий выбирается якобы с целью достижения переносимости? Неужели есть системы, под которые g++ не работает, ну или какой-нибудь другой компилятор C++?
Использование C++ решило бы множество рутинных проблем, описанных в статье, вроде использования std::vector для динамического распределения памяти, более безопасных функций работы со строками или написания своих обёрток над целыми числами с контролем переполнения.
Не то чтобы разбираюсь...
Curl поддерживает множество платформ, включая встраиваемые системы, ограниченные по ресурсам, и устаревшие ОС, не имеющие стандартной реализации необходимых библиотек.
Причём поддержкой некоторых платформ занимаются индивидуальные разработчики.
Использование современного стандарта C++ с одной стороны упростит добавление новой функциональности и избавит от необходимости тащить собственные велосипеды, с другой стороны потянет за собой новые зависимости, на которые просто не хватит ресурсов на некоторых из поддерживаемых платформ. Разработчики выбирают совместимость, в чём-то теряя в динамике развития.
Если когда-либо они изменят свой подход, сразу отпадёт половина платформ - просто некому будет заняться адаптированием новой кодовой базы. Ещё четверть растеряется позже.
А так - "curl is used ... in over twenty billion installations ... daily by virtually every Internet-using human on the globe."
Меня больше удивляет, что они используют древнейший стандарт для совместимости, однако отказались от поддержки 32-битных систем. Разве это не бьет по совместимости куда сильнее?
Они отказались не от поддержки 32 битных систем, а от каких-то древних компиляторов, которые не знают типы int64_t. Честно говоря, не встречал таких : для 8-битных MCU, типа атмеги или pic12 компиляторы поддерживают такие типы
curl, это не только консольная утилита, но и либа, которая поддерживает кучу языков, в том числе паскаль, ада95 или лисп. Думаю поэтому, С89.
Если когда-либо они изменят свой подход, сразу отпадёт половина платформ - просто некому будет заняться адаптированием новой кодовой базы.
Согласен. Есть платформы, которые имеют уникальную ситуацию, т.е. находятся в категории "другое". По отдельности каждая такая платформа - 0.1%, но когда объединишь - получается ощутимый процент.
Привет, это команда GitVerse! У тебя крутая статья, будем рады видеть тебя в сезоне open source. Для этого просто поставь тег "сезон open source" – и ты участвуешь :)
Как мы пишем код для curl на C