Полностью согласен. Только не DRM, а DRI. С момента появления первых композитных менеджеров окон эпоха протокола X11 прошла насовсем. В какой-то мере программы ещё продолжали общаться с Xlib, но уж точно не с X11 protocol. А это было очень давно. Это относилось даже к шрифтам. И с тех пор именно API DRI определял вектор развития оконных интерфейсов *nix. А поскольку стандарта DRI не существовало, тав вендоры работали с extensions, кто во что горазд. Вот и появилась идея создания низкоуровневого композитного менеджера, такого, как Wayland, а уж над ним конструкции низкоуровневого графического API, Vulcan. Кстати, именно после появления концепции связки Wayland/Vulkan, Apple задумалась о создании своего собственного низкоуровневого API (Metal). Apple, кстати, даже участвовала в консорциуме Vulcan, потом отвалилась от него.
Ни DRI, ни Wayland, ни Vulcan не имеют сетевого протокола как такового, потому что это физически нереализуемо с разумным уровнем полезности.
Так что темы, которая затрагивает эта статья прокисли году этак в 2006-м. Кстати, автор не отметил следующих особенностей/недостатков протокола:
Работа со шрифтами. Для нормальной работы шрифты на клиенте и сервере должны в точности совпадать. В протоколе не было механизма ни загрузки шрифтов, ни их предварительной передачи/кэширования.
Абсолютно перегруженный нелепыми понятиями и уровнями keyboard/mouse mapping, который никогда по-человечески не работал. Для этого они были вынуждены делать даже костыли через Dbus с пробросом сигнализации сторонним менеджерам мэппинга.
Ну и про DRI ничего не было сказано, хотя, как я сказал, года с 2006-го, X11 - это всего лишь оболочка над DRI для выделения границ окон.
Статья хорошая, спору нет. Но в в данном конкретном случае это решение избыточно примерно как микроскоп по отношению к гвоздям. достаточно набрать, например, в google play фразу "http proxy server", скачать тот, у кого меньше рекламы. Прописать на дивайте прокси. И радоваться. Там есть как http-прокси, так и socs, и даже прозрачные.
И да, как только явление станет более-менее массовым, зашейпят на раз. Ведь шейпят же и так "ping -f". Так что как эксперимент для себя - норм, как рабочее решение - ни о чём.
Я считаю, что GraphQL - крайне небезопасная спецификация с точки зрения security. Какие стандартные способы Spring (либо какие-то иные) существуют для авторизации запросов GraphQL. Нигде развития этой темы я серьёзно не видел, начиная с Метеора (Apollo), и кончая вот этими костылями. Да, все давно с помощью Spring Data научились прозрачно мэппить репозитории Spring Data на какие-то эндпоинты. Sprind Data REST (HATEOAS), OpenAPI (Swagger), odata (Olingo2). Но там речь идёт о семантике REST-endpoints, для которых подходит как стандартная Sping Security, так и куча других костылей. Как быть в случае GraphQL, природа не подсказывает. А чем он вообще лучше SQL через http(s)? За исключением агрегации запросов? Есть ли в java какие-то способы/фреймворки/библиотеки, поддерживающие солидную авторизацию (не аутентификацию) запросов с помощью GraphQL, и исключающие injection?
Не могу себе это представить. Это о каких языках вы говорите по отношению к Python?
Не могу представить себе более лаконичного решения любой задачи, чем на Python.
Приведите, пожалуйста, в пример эти нескольких строк кода. Просто интересно стало…
А всё потому, что вы не использовали дополнительную прокладку в виде service над репозиториями. Нсли бы она была, красноты стало бы существенно меньше.
Полностью согласен. Только не DRM, а DRI. С момента появления первых композитных менеджеров окон эпоха протокола X11 прошла насовсем. В какой-то мере программы ещё продолжали общаться с Xlib, но уж точно не с X11 protocol. А это было очень давно. Это относилось даже к шрифтам. И с тех пор именно API DRI определял вектор развития оконных интерфейсов *nix. А поскольку стандарта DRI не существовало, тав вендоры работали с extensions, кто во что горазд. Вот и появилась идея создания низкоуровневого композитного менеджера, такого, как Wayland, а уж над ним конструкции низкоуровневого графического API, Vulcan. Кстати, именно после появления концепции связки Wayland/Vulkan, Apple задумалась о создании своего собственного низкоуровневого API (Metal). Apple, кстати, даже участвовала в консорциуме Vulcan, потом отвалилась от него.
Ни DRI, ни Wayland, ни Vulcan не имеют сетевого протокола как такового, потому что это физически нереализуемо с разумным уровнем полезности.
Так что темы, которая затрагивает эта статья прокисли году этак в 2006-м. Кстати, автор не отметил следующих особенностей/недостатков протокола:
Работа со шрифтами. Для нормальной работы шрифты на клиенте и сервере должны в точности совпадать. В протоколе не было механизма ни загрузки шрифтов, ни их предварительной передачи/кэширования.
Абсолютно перегруженный нелепыми понятиями и уровнями keyboard/mouse mapping, который никогда по-человечески не работал. Для этого они были вынуждены делать даже костыли через Dbus с пробросом сигнализации сторонним менеджерам мэппинга.
Ну и про DRI ничего не было сказано, хотя, как я сказал, года с 2006-го, X11 - это всего лишь оболочка над DRI для выделения границ окон.
Статья хорошая, спору нет. Но в в данном конкретном случае это решение избыточно примерно как микроскоп по отношению к гвоздям. достаточно набрать, например, в google play фразу "http proxy server", скачать тот, у кого меньше рекламы. Прописать на дивайте прокси. И радоваться. Там есть как http-прокси, так и socs, и даже прозрачные.
И да, как только явление станет более-менее массовым, зашейпят на раз. Ведь шейпят же и так "ping -f". Так что как эксперимент для себя - норм, как рабочее решение - ни о чём.
Я считаю, что GraphQL - крайне небезопасная спецификация с точки зрения security. Какие стандартные способы Spring (либо какие-то иные) существуют для авторизации запросов GraphQL. Нигде развития этой темы я серьёзно не видел, начиная с Метеора (Apollo), и кончая вот этими костылями. Да, все давно с помощью Spring Data научились прозрачно мэппить репозитории Spring Data на какие-то эндпоинты. Sprind Data REST (HATEOAS), OpenAPI (Swagger), odata (Olingo2). Но там речь идёт о семантике REST-endpoints, для которых подходит как стандартная Sping Security, так и куча других костылей. Как быть в случае GraphQL, природа не подсказывает. А чем он вообще лучше SQL через http(s)? За исключением агрегации запросов? Есть ли в java какие-то способы/фреймворки/библиотеки, поддерживающие солидную авторизацию (не аутентификацию) запросов с помощью GraphQL, и исключающие injection?
Не могу представить себе более лаконичного решения любой задачи, чем на Python.
Приведите, пожалуйста, в пример эти нескольких строк кода. Просто интересно стало…
А всё потому, что вы не использовали дополнительную прокладку в виде service над репозиториями. Нсли бы она была, красноты стало бы существенно меньше.