Некоторые мысли о следующей версии sUTL

Я просматривал обрывки информации об операционной трансформации. Это было большим нововведением Google Wave, и есть множество забавных маленьких библиотек и кусочков, которые играют с ним.

Оперативное преобразование заключается в том, что если вы можете правильно описать изменения в сложной структуре данных, вы можете безопасно объединять изменения, внесенные несколькими людьми, без блокировки или какой-либо реальной координации.

Скажем, когда вы редактируете сложный документ (представьте себе большой текстовый документ, хотя он может быть и более сложным), вы описываете его как список небольших преобразований… прыгнуть вперед, вставить этот текст, прыгнуть немного дальше, удалить этот текст и так далее.

Если вы сделаете это именно так, вы сможете взять правки из двух источников, скажем, А и Б, и применить их к документу в любом порядке (А, затем Б или Б, затем А) и получить тот же результат, даже если человек, который сделал правку А не знал о Б и наоборот. Таким образом, вы можете затем отправить B человеку, который сделал A, и A человеку, который сделал B, они могут обновить свое представление о мире до A + B и двигаться дальше.

Он делает это посредством координации с сервером, принимая правки A и B и производя их специальные преобразования, чтобы все это работало. Еще больше здесь: http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation

Вы можете сделать это с текстом, но вы также можете сделать это с другими структурами. Неудивительно, что если вы читали какие-либо из моих предыдущих сообщений, я заинтересован в том, чтобы сделать это с данными JSON (например, MAS).

В этом пространстве уже есть действительно интересные попытки. Один из них, который я сейчас перевариваю, — это ShareJS. Вот их набор канонических преобразований: https://github.com/ottypes/json0

Во-первых, они сделали в ShareJS кое-что намного лучше для ссылки на документ MAS, чем JSONPath (который использует sUTL). Они просто делают это:

{‘p’: [‘ключ’, 2, ‘другой ключ’, …] }

т. е.: путь — это список строк и целых чисел, где строки — это ключи словаря, а целые числа — это индексы списка.

JSONPath намного сложнее, но я обнаружил, что sUTL не нуждается в такой сложности. Еще одна особенность JSONPath заключается в том, что вы можете использовать двойную точку «..key», чтобы обозначить «рекурсивный поиск ключа вниз по дереву», но это необычно и может быть заменено преобразованием только для этой работы.

Во-вторых, что гораздо более интересно, sUTL может включать в себя библиотеку операционных преобразований. Учитывая канонический набор (операционных) преобразований, как в документе ShareJS выше, sUTL может предоставить базовые (sUTL) преобразования для координации нескольких редакторов и поддержания основного документа в актуальном состоянии.

Это, очевидно, может быть использовано для нескольких человек, редактирующих документ JSON, хорошо. Но есть и более интересные применения.

Я думал о пользовательских интерфейсах и о том, как чертовски раздражает их создание. В современном мире существует множество отличных способов создания пользовательского интерфейса на основе javascript на стороне клиента для Интернета, и все они требуют сложных инструментов и такого внимания, которое может уделить только преданный разработчик внешнего интерфейса. Бле. А затем вы переходите к мобильным приложениям и т. д., все сделано с использованием совершенно разных парадигм, и все снова невероятно запутано.

Но что такое пользовательское приложение на самом деле?

Он включает в себя:

  • что-то вроде DOM; то есть: рекурсивная структура компонентов пользовательского интерфейса
  • немного стиля
  • куча государства
  • какой-то код
  • способность кода общаться с внешними вещами (например, делать веб-запросы)
  • возможность кодировать реакцию на события (например, нажатия кнопок, веб-ответы)

Я думаю, что DOM может быть указан в MAS, стили могут быть указаны в MAS, состояние — это просто данные и, конечно, может быть указано в MAS, а код sUTL может быть указан в MAS.

Итак, мы подошли к пользовательскому приложению, указанному как преобразование sUTL, например так:

{
  "manifest": { ... top level app config ... },
  "ui": { ... },
  "style": { ... },
  "state": { ... }
}

где вы можете разместить sUTL где угодно (потому что технически все это sUTL).

Мне нужно было бы определить целую базовую библиотеку пользовательского интерфейса. Например:

{
  "type": "button",
  "text": "Click Me",
  "onclick": <... some sUTL ...>
}

Как будет выглядеть «onclick»? Что ж, преобразованию sUTL потенциально потребуется доступ ко всему, поэтому источником может быть весь документ. Каким будет результат?

Может быть, список преобразований всего исходного документа, как в ShareJS?

Скажем, нажатие кнопки хочет добавить метку в пользовательский интерфейс, результатом sUTL onclick может быть

[
  {
    "p":["ui", ..., <idx>], 
    "li": {
      "type": "label",
      "text": "Hello World"
    }
  }
]

Таким образом, весь пользовательский интерфейс становится одной огромной самотрансформирующейся структурой JSON/MAS. Довольно круто!