А зачем ему знать? он видит запрос, и имеет на

него ответ. мини-редиска. не нужно ничего другого ему

запрос может отличаться

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

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

так не нужно это в большинстве случаев, зачем разработчику рвать жопу ради того, что никому (ну почти) не нужно, это просто не целесообразно

потом ещё всё это отлаживать

это относится к пункту про целесообразность

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

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

ты не понимаешь законы рынка? обычно делают то на что есть запрос, нет запроса нет и предложения, ибо если делать что-то без такого запроса это работа в пустую

еще раз, мы говорит про технику или про маркетинг? Есть огромный запрос на надежные машины, а их нет )

но скорее всего не придётся, или всё будет настолько просто, что оно будет проще супер универсальной логики внутри ядра

насчёт сети не знаю, но с устройствами такой фокус не прокатит

откуда тут ядро и "универсальная логика"? какая логика у редиски и прочих KV системах? - простейшая - сравнить и выдать.

абсолютно надёжных нет, и никогда не будет, вопрос в том насколько надёжное нужно и уверен техника с надёжностью которая удовлетворит большинство существует, а рвать жопу ради абсолюта ну это лишнее

ну, мы чегото перешли в область веры )

А платежеспособен ли этот запрос?

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

во и это тоже

ну так они есть близко к логике. сразу после приложения сидят, перед обращением к протоколам и ФС, и даже до драйверов устройств

ты знаешь что такое пайп?

знаю. и это понятия достаточно резиновое. в зависимости и масштаба рассмотрения

ты бы стал его кешировать?

если у тебя обмен данными идет по сетке. кто заставляет его кешировать?

ты, как бы странно это не звучало, ну а если точнее, то кеш что ты предлагаешь

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

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

с одной стороны соглашусь, однако "все есть файл" тогоже посикса с тобой спорит )

ужасная концепция