Просто как раз недавно делал интеграцию с ffmpeg — и у меня все эти флажки в «prepare» вызвали дежавю. В любом случае, наверняка там «внизу» что-то низкоуровневое -опенсорсное, никто свой велосипед писать не будет.
Насчет стандартов API: методы HTTP (на базовом уровне, конечно) вполне себе «стандартизируют» основные действия с данными — GET- запросы информации, POST — ее создание/измение, DELETE — соответственно, удаление
Отличный подход: ради внедренного в недрах Вольво способа позиционирования весь мир (или та его часть, где они хотят это внедрить) будет перекладывать дороги. А если вдруг какой-нибудь Ниссан придумает другой вид датчиков (скажем, оптические вместо магнитных)- не страшно, перелопатим дороги еще раз! И так для каждого «изобретателя»…
Обычно логика permissions чуть сложнее, чем «владельцу можно, а остальным — нет». Могут быть группы (вложеные), политики безопасности, суперюзеры и.т.д
Я про пассивное управление и говорю. При этом часто управляющий элемент знает своих «подчиненных», а они его — нет, так что выбирать кого-либо они не могут (отношения «caller -> callee»).
К примеру, живет себе web сервер (только что созданный из темплейта — так называемый «instance on demand») и в ус не дует — он и знать не знает что запросы к нему приходят не из внешнего интернета, а через прокси/лоад балансер
В описанной вами системе присутствует зависимость «клиент знает о лоад балансере(ах), которые его обслуживают», а это не всегда возможно. Например, в AWS у клиента может не быть ни малейшего понятия где он и почему запрос пришел именно к нему.
Мне кажется, речь идет о проблеме «курицы и яйца»:
Чтобы обеспечить «горячее» переключение при отказе узла на другой (избыточный), необходим узел «верхнего уровня», который прозводит мониторинг и непосредственно переключение (load balancer или кто-то подобный).
Указаная «отказонеустойчивость» описана именно среди узлов таких «load balance»-ов. Т.е, нужен «load balancer» для «load balancer»-ов. А соответственно, он ведь тоже может отказать, и тогда…
Вот и не хотят делать «бесконечную рекурсию».
Это довольно печально… Тогда с появлением все более и более «дружелюбных» CMS рынок будет мельчать и выродится в поделки студентов, умещих читать мануалы к ним. Ну и дезайнеры всегда свой хлеб найдут — картинки рисовать.
Тогда-то программисты к Джону и пойдут (судя по моему плодотворному сотруднечеству с украинцами)
Я просто был под впечатлением, что достаточно большая часть «пост-советского» IT работает на международных проектах (в той или иной степени). Возможно, это не касается вашей отрасли (или вообще мое впечатление ошибочно). Получается, что внутренний рынок вполне себе развит.
этото плагин делает короткий «индекс» продолжительных промежутков времени (часов/дней). Это очень помогает при расследовании всяких уже произошедших событий (начная от «кто стукнул машину на стоянке» до «кто террорист, который взорвал марафонцев в Бостоне».
А реагировать сразу — это утопия: никто не в силах одновременно смотреть на 10 000 камер в реальном времени (даже китайцы:))
К сожалению, обычно «нормальные» акционеры — довольно нервные особы и плохо реагируют на свои убытки (даже «на бумаге»), которые когда-нибудь (если вообще) будут возмещены. Более того — стабильно падающая цена на акции (не сиюминутный скачек)- это обычно показатель фундаментальных корпоративных (или даже отраслевых) проблем. Если вы- руководитель (а крупные акционеры ими по факту являются), то сидеть сложа руки — плохой способ с этими проблемами бороться.
когда говорят о том, что в результате падения акций компания потеряла столько то миллионов, то это не более чем красивые слова т.к. на самом деле никаких потерь, кроме имиджевых, здесь нет.
Компанией управляют держатели акций, которые потерпели прямой убыток. Они будут продавливать любые «телодвижения» (массовые увольнения, расподажу активов и.т.д), чтобы эти убытки минимизировать. Так что убытки тут далеко не «имиджевые».
Вот на этом шатком предположении и строится вся защита…
Как упражнение это все очень весело, а в продакшене даже HASP ломают
К примеру, живет себе web сервер (только что созданный из темплейта — так называемый «instance on demand») и в ус не дует — он и знать не знает что запросы к нему приходят не из внешнего интернета, а через прокси/лоад балансер
Чтобы обеспечить «горячее» переключение при отказе узла на другой (избыточный), необходим узел «верхнего уровня», который прозводит мониторинг и непосредственно переключение (load balancer или кто-то подобный).
Указаная «отказонеустойчивость» описана именно среди узлов таких «load balance»-ов. Т.е, нужен «load balancer» для «load balancer»-ов. А соответственно, он ведь тоже может отказать, и тогда…
Вот и не хотят делать «бесконечную рекурсию».
Тогда-то программисты к Джону и пойдут (судя по моему плодотворному сотруднечеству с украинцами)
А реагировать сразу — это утопия: никто не в силах одновременно смотреть на 10 000 камер в реальном времени (даже китайцы:))
Компанией управляют держатели акций, которые потерпели прямой убыток. Они будут продавливать любые «телодвижения» (массовые увольнения, расподажу активов и.т.д), чтобы эти убытки минимизировать. Так что убытки тут далеко не «имиджевые».