Вы показали ссылку на Гугл, где в выдаче находятся ресурсы, позволяющее сделать ресайз, загрузив изображение вручную или указав ссылку на него. Такой подход можно использовать только если эти действия делать вручную. Мы же ставим задачу реализации такого сервиса в виде АПИ, где само использование может быть автоматизировано.
В этом случае на клиент (в браузер) предварительно будет загружено исходное изображение. Если это 20 изображений по 5МБ, это существенно увеличит траффик.
Спасибо, на данном этапе мы надеялись на благоразумное использование. Если мы будем отправляться в большое плавание, косяки подобного рода обязательно будут устранены.
Вся суть в том, что мы предоставляем процессинг изображений в автоматическом режиме и нашему сервису абсолютно без разницы, где и кто пытается сделать ресайз. В основном, это как раз случаи, когда программист и понятия не имеет, что именно нужно ему будет обрабатывать. Вопрос исходников тут как раз не стоит остро — у грамотного специалиста не займет много времени написать подобного рода обработчик. С помощью нашего сервиса как раз и решается задача необходимости создания подобного обработчика.
Соглашусь. В большинстве случаев подобные сервисы работают по схеме «Больше обращений — больше стоимость». Как пример могу привести prerender.io. Но тут тоже есть определенный смысл — больше обращений означает востребованность исходного ресурса. Большая востребованность означает возможность получения выгоды (если это не благотворительная деятельность), что допускает возможные расходы, пусть и минимальные, на одну из компонент своей инфраструктуры.
Ну вообще очень интересно смотреть на то, как люди пытаются запретить то, что находится за пределами их компетентности. Объявить вне закона можно что угодно, но совесть надо же иметь. Немного напоминает действия в отношении Биткоин и криптовалюты в целом: мол, что-то надо сделать, а сделать-то нечего, кроме как сказать «ай-ай-ай, нельзя» или «НАСТОЯТЕЛЬНО рекомендуем не делать то-то, а делать то-то».
Иногда складывается впечатление, что тупые чиновники вообще не пользуются консультациями СПЕЦИАЛИСТОВ, прежде, чем делать какие-то пресс-заявления и принимать законы.
при том, что у меня не получилось найти нормальный фреймфорк на пхп, использующий ar. Наверное, уместнее сравнивать не фреймворк и язык, а фреймворк и фреймворк.
Ну может кто-нибудь прокомментирует из заминусовавших в чем я не прав? Речь идет об автоматизации работы с субд немного другого уровня. Я не говорю, что это не надо делать. Надо, конечно надо, и огромное спасибо автору за освещение этого вопроса и безусловно ему надо продолжить цикл статей, освещающих тему ar. Просто интересно наблюдать как пхп-шные программисты постепенно начинают использовать то, что уже давно успешно работает на рельсах.
Не поймите меня неправильно, но вот сколько раз наблюдал такую картину: делать ничего не умеют, а такое значение уделяют и брендингу, и неймингу, и маркетингу. Да, поплывет. Но далеко ли? И сколько же вариантов, когда ребята просто делают и делают это хорошо, не уделяя особого внимания всем этим деталям. Я не спорю, момент важный, но, наверное не на начальном этапе. Особенно, когда есть вопросы «А дальше что? Что делать дальше?» Делай свое дело, а там кривая выведет тебя и на брендинг и на все остальное, если оно того стоит, конечно.
Стоп. Если рассматривать криптографически стойкую функцию, то мы должны иметь: необратимость и стойкость к коллизиям разного рода.
Необратимость по определению хэш функйии должна присутствовать. Сама функциия нахождения коллизии по результату работы хэш функции и будет являться обратной. Такой вариант исключаем. Остается ваш вариант — «быстрая функция поиска коллизий». Понятие «быстрая» будет рассматриваться в контексте скорости вычисления самой хэш-функции. Гипотетически, можно иметь огромный словарь значений и тогда скорость работы функции будет равна скорости поиска значения. Если значение хэш функции использовать в качестве адреса, то коллизия может быть найдена за одну итеррацию — не зависимо от сложности вычисления самой хэш функции.
Вопрос в том — куда определить трудоемкость составления этого словаря?
Если ее учитывать в процессе поиска коллизии, то этот процесс однозначно сложнее вычисления самого значения. Иначе в чем смысл самой алгоритмизации вычисления хэш-функции?
Если же ее НЕ учитывать, то процесс поиска коллизии гипотетически для любой хэш-функции проще, чем ее вычисление.
Я достаточно некомпетентен в данном вопросе, но объясните — вот такое заключение верно ли:
Решение в принципе может быть найдено либо перебором, либо функцией. Проверить решение можно также — либо перебором, либо обратной функцией. Существование обратной функции для любой данной в принципе не всегда возможно (те же самые хэш-функции). Таком образом, трудоемкость поиска решения больше трудоемкости его проверки.
Или я что неправильно понимаю?
Иногда складывается впечатление, что тупые чиновники вообще не пользуются консультациями СПЕЦИАЛИСТОВ, прежде, чем делать какие-то пресс-заявления и принимать законы.
Необратимость по определению хэш функйии должна присутствовать. Сама функциия нахождения коллизии по результату работы хэш функции и будет являться обратной. Такой вариант исключаем. Остается ваш вариант — «быстрая функция поиска коллизий». Понятие «быстрая» будет рассматриваться в контексте скорости вычисления самой хэш-функции. Гипотетически, можно иметь огромный словарь значений и тогда скорость работы функции будет равна скорости поиска значения. Если значение хэш функции использовать в качестве адреса, то коллизия может быть найдена за одну итеррацию — не зависимо от сложности вычисления самой хэш функции.
Вопрос в том — куда определить трудоемкость составления этого словаря?
Если ее учитывать в процессе поиска коллизии, то этот процесс однозначно сложнее вычисления самого значения. Иначе в чем смысл самой алгоритмизации вычисления хэш-функции?
Если же ее НЕ учитывать, то процесс поиска коллизии гипотетически для любой хэш-функции проще, чем ее вычисление.
Или что не так?
Решение в принципе может быть найдено либо перебором, либо функцией. Проверить решение можно также — либо перебором, либо обратной функцией. Существование обратной функции для любой данной в принципе не всегда возможно (те же самые хэш-функции). Таком образом, трудоемкость поиска решения больше трудоемкости его проверки.
Или я что неправильно понимаю?