Лично мне «на листочке карандашом» было бы намного комфортнее. Хотя бы в силу того, что при планировании решений рукописной формой пользуюсь регулярно, а эти онлайн-блокноты каждый раз новые и у каждого свои нюансы поведения и отображения.
На форуме Bugzilla десятки участников проголосовали за поддержку BPG в браузере Firefox, но разработчики пока воздерживаются от этого, потому что стандарт HEVC не совсем патентно чист.
Это довольно мягко сказано. Формат требует лицензирования. Точка.
Firefox сейчас ориентируется на исключительно полностью открытые форматы. Так что ждать поддержки этого формата от Лисы — бесмыссленно. Да и от Хрома не стоит.
Есть две немного разных задачи:
1) Гарантировать, что от сервера к киленту придет ровоно то, что отправил сервер (и наоборот)
2) То же что в 1, но еще гарантировать, что никто (в том числе провайдер) не сможет узнать, что было внутри переданных данных
HTTPS обеспечивает 2. Но часто было бы достаточно 1 (просто подпись контента).
PS: Разработчики Java JIT как бы не дураки и тоже это учитывают. В частности, тот код, который выполняется всего несколько раз — даже не компилируется в байткод, а просто интерпретируется.
Пардон, оговорился. Статистический анализ ветвлений в коде, типов передаваемых аругментов и вызываемых методов. JIT-компилятор Java в процессе исполнения меняет исполняемый байткод с учетом этих данных. Причем в процессе работы сгенерированный байткод может меняться многократно.
Допустим у вас есть сервер, который примиает POST и GET запросы (представленные разными классами на уровне кода приложения). И какой-то кусок кода, который в зависимости от запросов что-то делает.
Если вы на такой сервер в рамках-стресс теста натравите непрерывный поток POST-запросов, то JVM может решить перекомпилировать некоторые методы под оптимальную обработку конкретно POST запроса (возможно в ущерб производительности GET-запросов).
Мир на C++ клином не сошелся. Да, это основной системный язык на данный момент. Но как язык — он не очень. Скорее всего в долгосрочной перспективе будет замещен чем-то другим.
А про производительность — чушь. Нередко та же Java обгонит программу на С++ за счет статистического анализа. Или, во всяком случае, отработает не хуже.
С одной стороны — некоторые пункты несколько преувеличены. С другой стороны — проблем хватает.
Думаю что всё же в долгосрочной перспективе Ripple или что-то подобое допилят до ума. Основная идея: не пытаться сделать одну глобальную валюту, а сделать возможность обмена чем угодно на основе системы «кредитов доверия» между отдельными участниками.
Для удовлетворения принципов этого «баззворда» разработали HTTP.
WAT? Что вы хотели этим сказать?
Во-первых, HTTP — не REST. Или вы может быть скажете, что такие вещи как Cookie и Keep-Alive полностью соответствуют REST?
Во-вторых, вы уверены, что HTTP именно под принципы REST разрабатывали? Особенно с учетом огромной разницы в годах появления?
В-тертьих, у конкретно REST есть все основные признкаи «buzzword»: 1) есть много-много разных определений, 2) соответствут система условиям REST в каждом конкретном случае или нет является свпорным вопросм, 3) термин (не решение!) продвигается на лево и направо.
Firefox сейчас ориентируется на исключительно полностью открытые форматы. Так что ждать поддержки этого формата от Лисы — бесмыссленно. Да и от Хрома не стоит.
1) Гарантировать, что от сервера к киленту придет ровоно то, что отправил сервер (и наоборот)
2) То же что в 1, но еще гарантировать, что никто (в том числе провайдер) не сможет узнать, что было внутри переданных данных
HTTPS обеспечивает 2. Но часто было бы достаточно 1 (просто подпись контента).
Простейший пример — сайт-визитка. С контактными данными. Зачем ему HTTPS?
PS: Разработчики Java JIT как бы не дураки и тоже это учитывают. В частности, тот код, который выполняется всего несколько раз — даже не компилируется в байткод, а просто интерпретируется.
Допустим у вас есть сервер, который примиает POST и GET запросы (представленные разными классами на уровне кода приложения). И какой-то кусок кода, который в зависимости от запросов что-то делает.
Если вы на такой сервер в рамках-стресс теста натравите непрерывный поток POST-запросов, то JVM может решить перекомпилировать некоторые методы под оптимальную обработку конкретно POST запроса (возможно в ущерб производительности GET-запросов).
А про производительность — чушь. Нередко та же Java обгонит программу на С++ за счет статистического анализа. Или, во всяком случае, отработает не хуже.
Думаю что всё же в долгосрочной перспективе Ripple или что-то подобое допилят до ума. Основная идея: не пытаться сделать одну глобальную валюту, а сделать возможность обмена чем угодно на основе системы «кредитов доверия» между отдельными участниками.
Во-первых, HTTP — не REST. Или вы может быть скажете, что такие вещи как Cookie и Keep-Alive полностью соответствуют REST?
Во-вторых, вы уверены, что HTTP именно под принципы REST разрабатывали? Особенно с учетом огромной разницы в годах появления?
В-тертьих, у конкретно REST есть все основные признкаи «buzzword»: 1) есть много-много разных определений, 2) соответствут система условиям REST в каждом конкретном случае или нет является свпорным вопросм, 3) термин (не решение!) продвигается на лево и направо.
Да и статью следовало бы назвать «Определение REST от Рой Филдинга (автора термина)».