Да вы всё верно говорите, но только одно непонятно. Зачем математические формулы переводить на русский, если их можно скопипастить? Как и графики. Тем более что всё это в разных форматах лежит на гитхабе. Что такого английского в математических формулах?
Полностью согласен. Только не 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 над репозиториями. Нсли бы она была, красноты стало бы существенно меньше.
Да вы всё верно говорите, но только одно непонятно. Зачем математические формулы переводить на русский, если их можно скопипастить? Как и графики. Тем более что всё это в разных форматах лежит на гитхабе. Что такого английского в математических формулах?
А коммутаторы со стыками PRI и синхронными матрицами коммутации они что, аналоговые, что ли?
Правильнее было бы сказать "теперь построены на коммутации пакетов, вместо коммутации каналов"
Полностью согласен. Только не 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 над репозиториями. Нсли бы она была, красноты стало бы существенно меньше.