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

MD>Давайте смотреть:
MD>

Git имени друга и товарища Л.Торвальдса — 313 DLL

ldd /usr/bin/git
    linux-vdso.so.1 (0x00007fffc57b5000)
    libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f5f6d96a000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f5f6d950000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5f6d92e000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f5f6d924000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f5f6d75e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f5f6dd18000)

Че-то в вашей венде с длл-ками странное происходит...

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

D>Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.

Интересно, а откуда сервер должен это знать?

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

C>1) Head-of-line blocking. Если CSS будет в 10Мб, то придётся ждать пока он весь проедет. В HTTP2 потоки будут мультиплексированы в одном соединении.

С другой стороны, если бровсер начинает отрисовывать до того, как приедет CSS, то в процессе поступления CSS он еще не раз все перерисует. Что пользователей (по крайней мере, меня) раздражает.

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

D>>Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.

Pzz>Интересно, а откуда сервер должен это знать?

Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение

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

vsb>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение

HTML парсить довольно затратно. Я не думаю, что это хорошая идея — парсить HTML на сервере. Если говорить о нормальных высоконагруженных сайтах, а не о поделках, на которые заходят 5 пользователей в день.

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

I>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту.

Я если у тебя пробелы в пути к фолдеру, то тоже заработает?

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

vsb>>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение

Pzz>HTML парсить довольно затратно.

Почему? Если не усложнять себе жизнь экзотическими юз-кейсами, его чуть ли не регэкспами можно парсить.

Pzz>Я не думаю, что это хорошая идея — парсить HTML на сервере. Если говорить о нормальных высоконагруженных сайтах, а не о поделках, на которые заходят 5 пользователей в день.

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

Если говорить о практике, то в nginx есть такие варианты:

Пушить конкретные ресурсы для конкретного URL:

    location = /demo.html {
        http2_push /style.css;
        http2_push /image1.jpg;
        http2_push /image2.jpg;
    }

Принимать инструкции с бэкэнда:

    location = /myapp {
        proxy_pass http://upstream;
        http2_push_preload on;
    }

Бэкэнд должен слать заголовки вида

Link: </style.css>; as=style; rel=preload, </favicon.ico>; as=image; rel=preload

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

·>А в чём проблема-то конкретно? Выбор есть — не хочешь использовать less и прочее из поставки, не используй.

Но на диске оно будет валяться.

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

Pzz>>HTML парсить довольно затратно.

vsb>Почему? Если не усложнять себе жизнь экзотическими юз-кейсами, его чуть ли не регэкспами можно парсить.

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

Они, к тому же, еще тормознее, чем нормальный парсер. По-моему, в 90% случаев народ их использует от неумения нормальные парсеры писать. Но в любом случае, не серверово это дело, HTML парсить...

vsb>Если говорить о практике, то в nginx есть такие варианты:

vsb>Пушить конкретные ресурсы для конкретного URL:
vsb>

vsb>    location = /demo.html {
vsb>        http2_push /style.css;
vsb>        http2_push /image1.jpg;
vsb>        http2_push /image2.jpg;
vsb>    }
vsb>

И при каждом обновлении контента перенастраивать nginx? Не самая светлая идея, на мой взгляд. Особенно если учесть, что ошибки в этом месте будут почти не видны, и будут лишь влиять на скорость загрузки. Разумеется, все нормальные люди один раз настроят эту штуку и порадуются, а потом благополучно забьют, и весь перевоначальный выигрыш в скорости загрузки постепенно пропадет по мере развития сайта,

vsb>Принимать инструкции с бэкэнда:
vsb>

vsb>    location = /myapp {
vsb>        proxy_pass http://upstream;
vsb>        http2_push_preload on;
vsb>    }
vsb>

От того, что парсинг вынесен на сервере в отдельный процесс, он не перестает быть парсингом на сервере.

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

Pzz>HTML нельзя парсить регулярными выражениями потому, что он не является регулярным языком.

Его надо не распарсить, а вытянуть теги. Для этого сложный парсер не нужен, достаточно простейшей машины состояний.

Pzz>Они, к тому же, еще тормознее, чем нормальный парсер. По-моему, в 90% случаев народ их использует от неумения нормальные парсеры писать. Но в любом случае, не серверово это дело, HTML парсить...

Правильные регулярные выражения на DFA работают быстро.

vsb>>Если говорить о практике, то в nginx есть такие варианты:

vsb>>Пушить конкретные ресурсы для конкретного URL:
vsb>>

vsb>>    location = /demo.html {
vsb>>        http2_push /style.css;
vsb>>        http2_push /image1.jpg;
vsb>>        http2_push /image2.jpg;
vsb>>    }
vsb>>

Pzz>И при каждом обновлении контента перенастраивать nginx? Не самая светлая идея, на мой взгляд. Особенно если учесть, что ошибки в этом месте будут почти не видны, и будут лишь влиять на скорость загрузки. Разумеется, все нормальные люди один раз настроят эту штуку и порадуются, а потом благополучно забьют, и весь перевоначальный выигрыш в скорости загрузки постепенно пропадет по мере развития сайта,

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

vsb>>Принимать инструкции с бэкэнда:
vsb>>

vsb>>    location = /myapp {
vsb>>        proxy_pass http://upstream;
vsb>>        http2_push_preload on;
vsb>>    }
vsb>>

Pzz>От того, что парсинг вынесен на сервере в отдельный процесс, он не перестает быть парсингом на сервере.

При чём тут парсинг? Это уже бэкэнд будет решать. Не обязательно там парсинг. Там может на джаве аннотации или что-то подобное.

Ну и в любом случае это всё уже детали реализации. server push в протоколе есть и польза от него на определённых сценариях есть. Как и вред (при долгом пинге и высокой скорости легко можно запушить юзеру мегабайты картинок прежде, чем он успеет сказать "не надо мне, я закешировал их уже" и потратить его мобильный трафик). Пользоваться или нет — дело сайтодела, никто не заставляет. Я бы на типичном сайте пользоваться не стал, лучше грамотно настроить кеширование, первый раз можно и потерпеть. Но если это сайт-визитка, по сути это аналог того, что все ресурсы просто суются прямо в страницу, только тут у браузера всё же есть шанс отказаться от их загрузки, тут оно пользу несёт.

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

I>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту.
Pzz>Я если у тебя пробелы в пути к фолдеру, то тоже заработает?
Если использовать exec("touch", "-p", path) — вполне.

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

I>>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту.
Pzz>>Я если у тебя пробелы в пути к фолдеру, то тоже заработает?
C>Если использовать exec("touch", "-p", path) — вполне.

А твой пример сработает, если у тебя path с минуса начинается?

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

vsb>>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение

Pzz>HTML парсить довольно затратно. Я не думаю, что это хорошая идея — парсить HTML на сервере. Если говорить о нормальных высоконагруженных сайтах, а не о поделках, на которые заходят 5 пользователей в день.

100 человек, 1000 в день это по твоей формуле высоконагруженый ?

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

I>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту.

Pzz>Я если у тебя пробелы в пути к фолдеру, то тоже заработает?

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

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

I>>>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту.
Pzz>>>Я если у тебя пробелы в пути к фолдеру, то тоже заработает?
C>>Если использовать exec("touch", "-p", path) — вполне.

Pzz>А твой пример сработает, если у тебя path с минуса начинается?

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

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

D>>Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.

Pzz>Интересно, а откуда сервер должен это знать?

Ниоткуда. Это разработчик должен знать, какая страница какие данные потребует.

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

vsb>>>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение

Pzz>>HTML парсить довольно затратно.

vsb>Почему? Если не усложнять себе жизнь экзотическими юз-кейсами, его чуть ли не регэкспами можно парсить.

Проще прийти к соглашению, что каждая страница подтаскивает не абы что, а вещи вида <page>-<chunk>.<asset>. Во время билда создается статическая часть мапы, во время обраотки запроса — динамическая. Когда сервер отсылает респонс, то у него готовы обе части.

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

vsb>Правильные регулярные выражения на DFA работают быстро.

Угу. Только любимые в народе pcre к таковым не относятся.

Pzz>>И при каждом обновлении контента перенастраивать nginx? Не самая светлая идея, на мой взгляд. Особенно если учесть, что ошибки в этом месте будут почти не видны, и будут лишь влиять на скорость загрузки. Разумеется, все нормальные люди один раз настроят эту штуку и порадуются, а потом благополучно забьют, и весь перевоначальный выигрыш в скорости загрузки постепенно пропадет по мере развития сайта,

vsb>Ну так про что угодно можно сказать, и про сжатие изображений и про всякие SEO-теги. Порядок нужно поддерживать и контролировать.

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

vsb>Ну и в любом случае это всё уже детали реализации. server push в протоколе есть и польза от него на определённых сценариях есть.

Да я что, спорю что ли. Гугловцы молодцы, протолкали свой немного-слишком-сложный протокол во всемирные стандарты. Скоро вон quic протолкают, от которого есть полторы работающие реализации, а потом им придется свои прошивки в киску проталкивать, чтобы не умирала под напором неожиданно возросшего UDP-трафика.

Ничего не поделаешь, корпорация добра, положение обязывает

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

I>Это непринципиально. Стоимость изменений нулевая. А вот товарищ загруз уже с рекурсивным созданием фолдеров. А еще надо кавычки добавить, переменные окружения и тд.

Cyberax в 100500 раз аккуратнее тебя, но все равно ляпнул эту ошибку (и еще одно, но это непринципиально). Представляю, сколько таких ошибок ляпаешь ты, и как весело их потом искать по всем скриптам

P.S. Кстати, тема кроссплатформенности ОЧЕНЬ хорошо раскрыта в языке Go. Вплоть до того, что почти с любой поддерживаемой платформы почти на любую другую можно кросс-компилироваться без особых усилий. И рекурсивное создание директорий у них в стандартной библиотеке тоже есть.

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

I>>>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту.
Pzz>>>Я если у тебя пробелы в пути к фолдеру, то тоже заработает?
C>>Если использовать exec("touch", "-p", path) — вполне.
Pzz>А твой пример сработает, если у тебя path с минуса начинается?

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