Такой вопрос: у нас есть метод, возвращающий текущее время (как пример). Логично, что он должен быть GET'ом, но при этом кешировать его явно не надо, ибо глупо. Решение в явном запрете кеширования со стороны сервера, или есть что-то умнее с учётом кеширования шарахалок по луне?
Ложное условие отлично прокатывает для проверки гипотезы — брекпоинт с заменой результата, но, поскольку, фактический возврат значения происходит в ntdll, её патч может поломать все остальные проверки для системы, что по идее не очень хорошо.
В некоторых ноутах, этот квадратный штекер двойной. Т.е. можно купить внешнюю докстанцию, которая автоматом подключит питание и всё остальное (сеть, монитор, usb). Т.е., например, приходите домой, подключаете ноутбук одним проводом и работаете.
Ок. понял, что есть в стандарте. Но используется ли она фактически? Просто вижу кучу проблем с этим: обрыв соединения сразу рушит все запросы, а дальше или забивать на проблемные соединения, или реализовывать логику по повторному докидыванию соединений. Или если один запрос длинный, все остальные встают в очередь и курят. На сервере необходимо реализовывать сложную логику по поддержке таких хитрых соединений с сильным взаимодействием между сервером и обработчиком.
Не очень понял следующую ситуацию: допустимо ли фигачить в одном соединении несколько реквестов, а потом получить пачку респонзов. И не снесёт ли башню серверу от такой логики?
В моём телефоне подобный режим сделал производитель, в результате, все бьются с проблемой «сообщения не доходят, когда телефон лежит на столе в спячке». Тут, судя по описанию будет тоже самое. Или же, если приложениям будет дана возможность всё равно будить телефон, все сразу же ей воспользуются.
А при плохом освещении итак не видно что на калькуляторе. :)
У меня был такой, на чистых солнечных батарейках, никаких проблем не было с ним. Правда, это был совсем не 78-ой год.
Мы используем подобные решения в нескольких проектах. Очень удобно: у нас всегда есть пользователь, т.е. не надо делать страницу авторизации, пользователю не надо придумывать отдельный пароль, мы знаем имя пользователя, возможность быстрого импорта пользователей (просто файлы с сертификатами).
Но, к сожалению, есть недостатки: клиентские сертификаты более требовательны к качеству криптографии (то Microsoft с апдейтами начудит и всё сломает, то Chrome решит истерить), для FF приходится вручную импортировать сертификат, с мобильными браузерами множество проблем (кто-то не поддерживает, импорт сертификатов приводит к некоторому геморрою).
Кстати, а что с ЭЦП делать. Вариантов, как бы нет, нужно пролезать в систему. Раньше это решалось через ActiveX (и Microsoft до сих пор предоставляет «неподдерживаемый» CAPICOM), в других браузерах через NPAPI (тоже умирает). Было ещё решение через Java, которая сам работает через ActiveX, при этом хранилище сертификатов у неё своё.
А теперь я не вижу, что можно для этого использовать ещё. Хоть мне и не нравится ActiveX, но, блин, замену-то приличную предложите.
Это не .NET Framework и к нему не имеет отношения. Соответственно не имеет отношения к вашему первоначальному высказыванию.
И это C++ Runtime, т.е. библиотека для запуска приложений, написанных на C++ с помощью Visual Studio. Распространяется отдельно, т.к. этот рантайм разбух до неприличных размеров, чтобы засовывать его в каждый файл, он требуется куче приложений, поэтому лучше поместить в отдельное место, и к нему могут выходить апдейты и багфиксы со стороны Microsoft, которые не будут требовать перекомпиляции приложения.
Вы из какого года это пишете? Framework уже с Vista поставляется, лезет через апдейты, а количество программ, его требующих превышает все разумные пределы.
Сервер может вернуть ошибку, если он динамический (или какой-нить nginx выплюнуть 502), а т.к. иконка обычно отдаётся статикой — она может загрузиться.
С внутрисетевым есть две проблемы:
1. в разных регионах разные цены на связь (в Москве самые дорогие), надо затруднить перетекание симок из одного региона в другой (съездил в тверь, купил симку, пользуешься в Москве).
2. Наше правительство обязывает операторов пропускать междугородние звонки через внешние каналы (Ростелеком жадно потирает ручки). В результате, вместо того, чтобы обслуживать вас внутри сети, приходится магистралить за деньги чужому дяде.
У меня был такой, на чистых солнечных батарейках, никаких проблем не было с ним. Правда, это был совсем не 78-ой год.
Но, к сожалению, есть недостатки: клиентские сертификаты более требовательны к качеству криптографии (то Microsoft с апдейтами начудит и всё сломает, то Chrome решит истерить), для FF приходится вручную импортировать сертификат, с мобильными браузерами множество проблем (кто-то не поддерживает, импорт сертификатов приводит к некоторому геморрою).
А теперь я не вижу, что можно для этого использовать ещё. Хоть мне и не нравится ActiveX, но, блин, замену-то приличную предложите.
И это C++ Runtime, т.е. библиотека для запуска приложений, написанных на C++ с помощью Visual Studio. Распространяется отдельно, т.к. этот рантайм разбух до неприличных размеров, чтобы засовывать его в каждый файл, он требуется куче приложений, поэтому лучше поместить в отдельное место, и к нему могут выходить апдейты и багфиксы со стороны Microsoft, которые не будут требовать перекомпиляции приложения.
Это как раз родной С++
1. в разных регионах разные цены на связь (в Москве самые дорогие), надо затруднить перетекание симок из одного региона в другой (съездил в тверь, купил симку, пользуешься в Москве).
2. Наше правительство обязывает операторов пропускать междугородние звонки через внешние каналы (Ростелеком жадно потирает ручки). В результате, вместо того, чтобы обслуживать вас внутри сети, приходится магистралить за деньги чужому дяде.