Ну так сервис «обработать картинку, представленную в виде байт-массива, и вернуть байт-массив» — общедоступен и общепонятен как раз.
Нет, потому что он не решает никакую конкретную прикладную задачу, подменяя её абстрактной системной. Как, например, и фраза «запустить приложение».
Ну так интерфейсом это как раз предусмотрено. Интерфейс вполне может явно написать «здесь — JSON».
Если речь идёт о передаче внешнего JSON-кода — пожалуйста. Аналогично, для передачи внешних HTTP-хедеров, интерфейс может содержать коллекции именованных свойств (хотя основные/стандартные заголовки, несомненно, пойдут в основной интерфейс). Вопрос в том, что подобное представление не может возникнуть спонтанно, без нужды к тому, как в примере с описанием стиля текста.
А это именно то, про что я вам, кажется, уже говорил раньше
Да, говорили. Я в прошлой статье как раз писал, как это предполагается обойти.
А реализация-то откуда возьмется? Где-то ее надо сделать.
В месте возникновения картинки.
Что веселее, я хочу эту картинку в своем приложении обработать, его алгоритмами — и это значит, что мне нужно ее исходное тело, а не какая-то абстрация поверх.
«Своих приложений» в данной системе нет. Модуль либо предоставляет общедоступные сервисы общепонятным способом, либо не существует. Систем, позволяющих писать несовместимые чёрные ящики, и так хватает.
Вы же понимаете, что где строка, там и структурированное представление, а где структурированное представление, там и произвольная информация?
Попытка использовать поля интерфейса для передачи не предусмотренной интерфейсом информации является нарушением условий сотрудничества.
… но при этом передать их без словаря ключ-значение не получится. И что делать?
Вы не поверите =)
Вот только приложению это невыгодно, это слишком долго.
Никакого принуждения. Разрабатывайте под платформы, под которые выгодно.
Как с картинками. Через интерфейс «Картинка». Не делая предположений о том, что у неё внутри — вдруг там вектор или анимация?
Массивы символов передавать можно?
Только как строки.
Для меня заголовки — это основная информация в HTTP-ответе (особенно в 202, 204 или 302).
Для меня тоже.
А как вы одно от другого отделяете?
Отвечая на вопрос о том, для чего предназначен данный интерфейс.
А какая разница? Написано же «не допускается», значит везде не допускается. Или нет?
Не допускается в качестве дополнительной информации. Например, интерфейс «Стиль текста», содержащий флаги IsBold, IsItalic и перечисление StrikeStyle (None, Underline, Overline, Strikethrough) не содержит коллекции, куда можно было бы воткнуть строки с цветом и размером шрифта: если эти данные ещё не поддерживаются в оригинальном интерфейсе, нужно расширять его соответствующими общедоступными членами, а не прикручивать x-foobar-extensions.
Зависит от контекста. В большинстве API просто не будет методов, котрорые их принимают. В сценариях вроде передачи данных в сокет — да, можно, только сокеты доступны лишь тем модулям, которым это надо для работы.
Вот, например, возьмем заголовки в HTTP-протоколе или куки в нем же… Как их, бишь, реализовывать без коллекции именованных свойств?
В данном случае речь не о дополнительной информации, а об основной. Дальше собственно интерфейса «HTTP-ответ» она в таком виде всё равно не пойдёт.
Добрый день. Пограммы работают с файлами через некоторый API, доступный, назовём это так, в SDK операционной системы. Этот SDK доступен любому языку программирования, который в принципе может нацеливаться на данную ОС.
Собственно, сам поворот — в расширении понятия SDK, в выносе в него всех предметных концепций, а не только низкоуровневых. Запуск модулей в общей среде — распространённая практика, тот же CLR это позволяет. Когда запускается модуль с известным API, контролировать, что именно он вызывает, становится легко.
Добрый день.
ABI специфический, ориентированный на взаимодействие в объектно-ориентированной среде (возможно, что-то близкое к CLR). Хотя непосредственно термин Application Binary Interface применять не совсем корректно из-за отсутствия чего-либо, что можно было бы называть приложением в этой среде.
Загрузчик на данный момент не выбран.
Управление памятью зависит от режима запуска — например, при работе в качестве агента под другой OS управлением памятью занимается она.
Ядро — гибридное, с заточкой под модульность.
Файловая система — специфическая, объектно-ориентированная.
Язык — C++.
Nix, Posix — нет.
А вообще, Вы во многом правы. Проблема человеческой непорядочности в общем виде действительно не решается даже в юриспруденции, не говоря уже о программировании. Но это не мешает иметь отдельные островки порядочности и отдельных хороших людей вокруг себя.
Точно так же, к примеру, свободный софт не решает проблемы привязки к проприетарным решениям, но где бы мы были без свободного софта?
Для пользователей всё выглядит так, что этот софт работает идеально, а чужой софт, подключающий его модули, глючит.
Не совсем так. Не нужно смотреть на автора софта как на автора всего стека модулей (аналога приложения), которыми пользователь начинает обмазываться с места в карьер. У пользователя, скорее всего, в системе уже стоит любимый интерфейс, через который все мессенджеры работают, любимый менеджер уведомлений, который мигает светом в аквариуме при получении нового сообщения, любимый плейер, который выводит mp3шечки на колонки в зале, и так далее. Если после установки нового интерфейса мессенджера в нём не видны сообщения из других клиентов, или если новый модуль подключения к серверу обмена сообщениями не работает со старым менеджером уведомлений, или если пересланные песни начинают проигрываться с ноутбука, пользователь с большой вероятностью откатится и забудет. Смысл нарезки софта на зоны ответственности состоит как раз в том, чтобы отвязать пользователя от платформы, позволяя получить от каждой по крупице.
Такой автор софта, как минимум, получит пустое множество в том месте, где у других авторов будет список совместимых с их модулем модулей (формируемом, в том числе, путём прогона тестов, с соответствующими мерами против оптимизации под конкретный тест). Соответственно, пользователи, которые пришли на данную ОС ради её преимуществ, увидят, что данный софт их существенно ограничивает, и с большой вероятностью предпочтут конкурентов. Как максимум — нарушит условия лицензии (хотя до обсуждения таких тонкостей я пока не дозрел от слова «совсем»).
Кроме того, такое поведение просто неэффективно с точки зрения бизнеса. То же можно провернуть под любой популярной ОС на выбор, и ценой гораздо меньших усилий. Это всё равно что пытаться построить универсальную DRM-систему, покрывающую все линуксы, а потом просить пользователей добровольно отказаться от возможности рутоваться.
Ещё одной проблемой стандарта HTML является отсутствие библиотеки тесткейзов с адекватным покрытием. С учётом разницы между платформами, под которую адаптирован этот язык, дело написания таких «юнит-тестов» является достаточно сложным, но не безнадёжным.
Проблемы начались в тот момент, когда имплементации бежали впереди стандарта (эпоха мегабитвы IE vs NN). На данный момент благодаря активным действиям W3C ситуация стала гораздо лучше.
Аналогично, путаница, привнесённая Borland C++, Managed C++ и т. п., заметно улеглась с возобновлением работ по стандартизации и выходом C++11/14/17.
Да. В эту же категорию попадают, например, телемеханические протоколы (Modbus/IEC) и даже языки программирования (всяческие ECMA, ISO C++ committee и прочие).
Если речь идёт о передаче внешнего JSON-кода — пожалуйста. Аналогично, для передачи внешних HTTP-хедеров, интерфейс может содержать коллекции именованных свойств (хотя основные/стандартные заголовки, несомненно, пойдут в основной интерфейс). Вопрос в том, что подобное представление не может возникнуть спонтанно, без нужды к тому, как в примере с описанием стиля текста.
Да, говорили. Я в прошлой статье как раз писал, как это предполагается обойти.
«Своих приложений» в данной системе нет. Модуль либо предоставляет общедоступные сервисы общепонятным способом, либо не существует. Систем, позволяющих писать несовместимые чёрные ящики, и так хватает.
Попытка использовать поля интерфейса для передачи не предусмотренной интерфейсом информации является нарушением условий сотрудничества.
Вы не поверите =)
Никакого принуждения. Разрабатывайте под платформы, под которые выгодно.
Только как строки.
Для меня тоже.
Отвечая на вопрос о том, для чего предназначен данный интерфейс.
Не допускается в качестве дополнительной информации. Например, интерфейс «Стиль текста», содержащий флаги IsBold, IsItalic и перечисление StrikeStyle (None, Underline, Overline, Strikethrough) не содержит коллекции, куда можно было бы воткнуть строки с цветом и размером шрифта: если эти данные ещё не поддерживаются в оригинальном интерфейсе, нужно расширять его соответствующими общедоступными членами, а не прикручивать x-foobar-extensions.
В данном случае речь не о дополнительной информации, а об основной. Дальше собственно интерфейса «HTTP-ответ» она в таком виде всё равно не пойдёт.
Собственно, сам поворот — в расширении понятия SDK, в выносе в него всех предметных концепций, а не только низкоуровневых. Запуск модулей в общей среде — распространённая практика, тот же CLR это позволяет. Когда запускается модуль с известным API, контролировать, что именно он вызывает, становится легко.
ABI специфический, ориентированный на взаимодействие в объектно-ориентированной среде (возможно, что-то близкое к CLR). Хотя непосредственно термин Application Binary Interface применять не совсем корректно из-за отсутствия чего-либо, что можно было бы называть приложением в этой среде.
Загрузчик на данный момент не выбран.
Управление памятью зависит от режима запуска — например, при работе в качестве агента под другой OS управлением памятью занимается она.
Ядро — гибридное, с заточкой под модульность.
Файловая система — специфическая, объектно-ориентированная.
Язык — C++.
Nix, Posix — нет.
Без поддержки интерфейсов со стороны разработчиков ОС эта система нежизнеспособна. Будет ли эта поддержка платной или бесплатной, не принципиально.
Точно так же, к примеру, свободный софт не решает проблемы привязки к проприетарным решениям, но где бы мы были без свободного софта?
Будет.
Кроме того, такое поведение просто неэффективно с точки зрения бизнеса. То же можно провернуть под любой популярной ОС на выбор, и ценой гораздо меньших усилий. Это всё равно что пытаться построить универсальную DRM-систему, покрывающую все линуксы, а потом просить пользователей добровольно отказаться от возможности рутоваться.
Аналогично, путаница, привнесённая Borland C++, Managed C++ и т. п., заметно улеглась с возобновлением работ по стандартизации и выходом C++11/14/17.