Здравствуйте, CreatorCray, Вы писали:

P>>рендерер мультипарт запроса. Или у вас рендерер это "когда картинко" ?
CC>multipart это scatter/gather логика а не render

Это вы про ваше апи клиента или особенности реализации этого компонента.
Render это перевод данных из одной репрезентации в другую. Parse — обратный процесс.
Вам нужно и то, и другое.

P>> Похоже, вы начали изобретать вебн
CC>Запросы данных из data source это не веб вовсе, там просто транспорт через HTTP

HTTP это основа веба.

P>>Говорите серверу "дай мне всё если поменялось с прошлого раза", а он вам "304 Not Modified"
CC>Ни один из моих data source не возвращает 304 в принципе. Они банально на своей стороне не хотят ничего за тебя отслеживать.

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

Здравствуйте, AlexGin, Вы писали:

П>>безгуйных демонов можно писать, да
AG>
AG>Так и не только демонов.
AG>Обычные CLI приложения, которые так популярны по сей день в Linux, также создаются в POSIX API легко и просто!

Посикс здесь ни при чем. CLI приложения на порядки проще своих аналогов но с GUI. Интерактив минимальный или вовсе отсутствует. Если вам вдруг вздумается запилить CLI приложение с тяжелым развесистым интерактивом, посикс на этом фоне будет в микроскоп не виден.
Т.е. в норме фронтенд для какой консольной утилиты занимает кодом в десятки или сотни раз больше нежели сама утилита.

Здравствуйте, Shmj, Вы писали:

V>>По сути вся компьютерная индустрия построена на двух языках.
V>>1. Операционка, драйвера, базы данных, веб-серверы и прочее на Си.
V>>2. Графические, физические, игровые движки, САПР, и куча других проектов на C++.

S>Это общего назначения софт — которы бесполезен сам по себе.

S>Реальная польза людям идет от банальных бухгалтерских|ERP программ — чтобы вам зарплату платить,

Какая интересная у человека картина мира! Его жизнь — это только торговля.
Ничего другого человек не замечает. Вот вообще. Ни науку, ни технику (автомобили те же самые), ни бытовые действия, ни медицину.

P>Просто яблоко ориентировано на дорогой сегмент в продуктах, потому пока сидит ровно.

Есть и другой фактор. В отличие от всех этих гуглов-фейсбуков, Яббл нанимает по старинке, в конкретные команды. То есть не просто "наберите мне 3000 человек, чем занять — потом придумаем" (как по мне так ужасный подход, но почему-то двигаемый как "новаторский"), а именно что "нам нужен инженер в команду распределенной билд-системы для внутренней автоматизации".

Я не знаю, совместим ли такой подход с традиционным для фейсбука "мы открываем новое направление, прайваси, и даем туда 3,000 инженерного поголовья" — что ведет к массовым миграциям всех карьеристов на new shiny thing.

Здравствуйте, alpha21264, Вы писали:

A>Какая интересная у человека картина мира! Его жизнь — это только торговля.

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

A>Ничего другого человек не замечает. Вот вообще. Ни науку, ни технику (автомобили те же самые), ни бытовые действия, ни медицину.

Наука и медицина — это там, на западе — этим занимается высшая цивилизация. У нас какая может быть наука? Медицинские приборы все так же оттуда.

Я это не отрицаю, но здесь собрались простые смертные — это не нашего уровня материи.

Здравствуйте, Pauel, Вы писали:

P>Render это перевод данных из одной репрезентации в другую. Parse — обратный процесс.
"На берегу реки доярка доила корову, а в воде отражалось всё наоборот" (С)

P>HTTP это основа веба.
Веб нынче это куда больше чем просто HTTP

P>Подождите пару лет, поработайте с самыми разными датасорсами, хттп-рест-апи итд, и увидите во что превратится ваш хттп клиент.
Первая имплементация была почти ровно 10 лет назад, в апреле 2014го. С тех пор датасурсы только добавляются. И клиент ни во что так и не превратился.
Народ на backend ж не тупой — в крайности не ударяется, API у всех максимально простой как доска.

Здравствуйте, AlexGin, Вы писали:

Pzz>>Смотря где. У glibc, которая отвечает за POSIX API, с совместимостью всё хорошо. Прям даже очень хорошо. Ну а более другие библиотеки, с ними по-разному.

П>>безгуйных демонов можно писать, да
AG>
AG>Так и не только демонов.
AG>Обычные CLI приложения, которые так популярны по сей день в Linux, также создаются в POSIX API легко и просто!

Ну да, потому все эти GNU/Linux'ы до сих пор в жопе и сидят, что ничего большего стабильного, кроме POSIX, так и не смогли сделать. И ладно бы была одна экосистема, как у яблочников, в рамках которой они запланированно вводят несовместимость раз в N поколений, у этих же десятки разнородных экосистем

Здравствуйте, CreatorCray, Вы писали:

P>>Подождите пару лет, поработайте с самыми разными датасорсами, хттп-рест-апи итд, и увидите во что превратится ваш хттп клиент.
CC>Первая имплементация была почти ровно 10 лет назад, в апреле 2014го. С тех пор датасурсы только добавляются. И клиент ни во что так и не превратился.
CC>Народ на backend ж не тупой — в крайности не ударяется, API у всех максимально простой как доска.

Это какой то совсем вырожденный случай.
На это говорит тот факт, что вы например про етаг не в курсе.
В норме апи бакенда эволюционирует, тк потребности внешнего мира меняются.
Выглядит так, что у вас не хттп клиент, а частный случай под набор крайне консервативных бакендов.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, AlexGin, Вы писали:

П>>>безгуйных демонов можно писать, да
AG>>
AG>>Так и не только демонов.
AG>>Обычные CLI приложения, которые так популярны по сей день в Linux, также создаются в POSIX API легко и просто!

P>Посикс здесь ни при чем. CLI приложения на порядки проще своих аналогов но с GUI.

Это иногда так, а иногда и совсем не так. Есть CLI приложения и "демоны" имеющие большую алгоритмическую сложность (анализ спектра сигнала, поиск и т.д.).
По сравнению с этими алгоритмами — реакция на события и отрисовка ректангуляра, что характерно для GUI-application, не выглядит сложно.
Часто даже в сложных приложениях с GUI, кажется что именно поддержание работы графического интерфейса — одна из рутинных несложных функций.

P>Интерактив минимальный или вовсе отсутствует. Если вам вдруг вздумается запилить CLI приложение с тяжелым развесистым интерактивом, посикс на этом фоне будет в микроскоп не виден.

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

P>Т.е. в норме фронтенд для какой консольной утилиты занимает кодом в десятки или сотни раз больше нежели сама утилита.
Опять же — зависит от...
Не думаю, что в бухгалтерских аппликухах самое сложное будет ГУЙ. Скорее криптография.

Здравствуйте, Pauel, Вы писали:

P>Это какой то совсем вырожденный случай.
У меня ж не Web. Я тупо json/xml получаю в ответ на запрос. Ну и гугловский OAUTH2 + запулить/стянуть блоб.

P>На это говорит тот факт, что вы например про етаг не в курсе.
Я его вживую не встречал вообще нигде откуда данные таскаю.

P>Выглядит так, что у вас не хттп клиент, а частный случай под набор крайне консервативных бакендов.
Я в нём имплементирую именно то, что мне требуется.
Понадобится — допишу
Писать сразу всемогутор — смысл?

Здравствуйте, AlexGin, Вы писали:

AG>Не думаю, что в бухгалтерских аппликухах самое сложное будет ГУЙ. Скорее криптография.
Он и будет.
А для криптографии там используются готовые готовые крипртопровайдеры и криптоAPI от OS.

Здравствуйте, AlexGin, Вы писали:

AG>По сравнению с этими алгоритмами — реакция на события и отрисовка ректангуляра, что характерно для GUI-application, не выглядит сложно.

Отрисовка ректангуляра — такими вещами можно пренебречь, это примитивы которые берутся забесплатно. В UI самое сложное это стейт-менеджмент.

AG>Часто даже в сложных приложениях с GUI, кажется что именно поддержание работы графического интерфейса — одна из рутинных несложных функций.

В примитивных приложениях так и будет, но это скорее исключение.

P>>Интерактив минимальный или вовсе отсутствует. Если вам вдруг вздумается запилить CLI приложение с тяжелым развесистым интерактивом, посикс на этом фоне будет в микроскоп не виден.
AG>
AG>Интерактив кстати имеется — им надо уметь воспользоваться.

Где можно посмотреть на чудеса интерактива в терминале?

P>>Т.е. в норме фронтенд для какой консольной утилиты занимает кодом в десятки или сотни раз больше нежели сама утилита.
AG>Опять же — зависит от...
AG>Не думаю, что в бухгалтерских аппликухах самое сложное будет ГУЙ. Скорее криптография.

Ога — в бухгалтерских приложениях вы криптографию сами никогда не пишете. Все ваши усилия уйдут на реализацию БЛ связанную с изменениями в законодательстве, куче всевозможных форм-отчетов итд итд.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, AlexGin, Вы писали:

AG>>По сравнению с этими алгоритмами — реакция на события и отрисовка ректангуляра, что характерно для GUI-application, не выглядит сложно.

P>Отрисовка ректангуляра — такими вещами можно пренебречь, это примитивы которые берутся забесплатно. В UI самое сложное это стейт-менеджмент.

Всё больше приложений, которые выглядят как сайт. Ну по сути браузер и сверстанные странички. Я понимаю, когда это делает условная Meta, у них уже есть условный Facebook с тоннами затраченных усилий на фронтэнд, и дешевле все готовое перенести на тот же Андроид в приложение.
Но иногда и сайта нет, чисто приложение, но для него всё равно берут браузерный движок и делают гуй на html. Не понимаю логику, разве что фронтэндщики идут по 5 копеек за пучок

Здравствуйте, wl., Вы писали:

wl.>Всё больше приложений, которые выглядят как сайт. Ну по сути браузер и сверстанные странички. Я понимаю, когда это делает условная Meta, у них уже есть условный Facebook с тоннами затраченных усилий на фронтэнд, и дешевле все готовое перенести на тот же Андроид в приложение.

UI нужно пилить на мейнстриме, это дешевле и в краткосрочной, и в долгосрочной перспективе. Сейчас мейнстрим это веб-технологии.

wl.>Но иногда и сайта нет, чисто приложение, но для него всё равно берут браузерный движок и делают гуй на html.

Собственно приложение с браузерным движком при желании легко сделать сайтом — у вас почти что одна кодовая база будет на все случаи

> Не понимаю логику, разве что фронтэндщики идут по 5 копеек за пучок

Платформенные разработчики тоже стоят денег. И пилить хотя бы две платформы — так себе идея.

AG>Не думаю, что в бухгалтерских аппликухах самое сложное будет ГУЙ. Скорее криптография.

А что вообще сложного может быть в криптографии? Если не ударяться в cutting edge со всякими там key derivation, все остальное уже очень хорошо изучено и понятно.

Здравствуйте, Pauel, Вы писали:

P>Посикс здесь ни при чем. CLI приложения на порядки проще своих аналогов но с GUI. Интерактив минимальный или вовсе отсутствует. Если вам вдруг вздумается запилить CLI приложение с тяжелым развесистым интерактивом, посикс на этом фоне будет в микроскоп не виден.

Ну, я бы поспорил. Не надо путать содержательную сложность со сложностью интерфейса.

Я бы не сказал, что gcc — простая программа, хоть она и cli. Или что cups — простая программа, хоть он и бессловестный демон.

P>Т.е. в норме фронтенд для какой консольной утилиты занимает кодом в десятки или сотни раз больше нежели сама утилита.

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

И если "утилита" сама по себе нетривиальна, нередко это приводит к разрезанию ее на содержательную библиотеку, общую для gui и cli, и интерфейсную часть.

wl.>Но иногда и сайта нет, чисто приложение, но для него всё равно берут браузерный движок и делают гуй на html. Не понимаю логику, разве что фронтэндщики идут по 5 копеек за пучок

Сейчас сайта нет, завтра есть — так что на браузерном движке может быть более futureproof. Опять же, проще переносить между платформами.

Хотя, разумеется, качественное приложение должно быть native

Здравствуйте, Pauel, Вы писали:

AG>>По сравнению с этими алгоритмами — реакция на события и отрисовка ректангуляра, что характерно для GUI-application, не выглядит сложно.

P>Отрисовка ректангуляра — такими вещами можно пренебречь, это примитивы которые берутся забесплатно. В UI самое сложное это стейт-менеджмент.

Я думаю, в UI самое сложное — это формулирование системы метафор, позволяющих изложить происходящее под капотом понятным человеку образом.

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

Здравствуйте, SkyDance, Вы писали:

SD>А что вообще сложного может быть в криптографии? Если не ударяться в cutting edge со всякими там key derivation, все остальное уже очень хорошо изучено и понятно.

Самое сложное в криптографии — это понимание границ своей компетентности и воздержание от их перехода. В криптографии очень легко насвистеть так, что это долго никто не заметит. А потом заметят нехорошие какие-нибудь люди.

Здравствуйте, Shmj, Вы писали:

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

Без компилятора тоже прожить нельзя. Без него не будет ни игрушек, ни программ для торговли, ни вообще ничего.

S>Наука и медицина — это там, на западе — этим занимается высшая цивилизация. У нас какая может быть наука? Медицинские приборы все так же оттуда.

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

S>Я это не отрицаю, но здесь собрались простые смертные — это не нашего уровня материи.

Не говори, пожалуйста, за всех.