Коллекции есть, Set и Vector, и можно подписываться на события в объектах коллекции. Вручную отсортировать / профильтровать тоже можно.
Но обернуть запрос к БД в виде коллекции и слушать его — пока нельзя, но такой функционал в работе. Собственно, он неизбежно бекендо-зависимый, отдельная реализация для SQL, отдельная для Mongo, итд.
1. В случае Causal trees конкурентные правки не перетираются. Там формально дерево символов, обход (depth first traversal) которого является текстом. Символы в дерево только добавляются. Timestamp используется для адресации и для упорядочения сиблингов (конкурентно вставленных в то же место символов). В Causal trees конфликтов, как таковых, нет.
2. Подписка идёт на объект, у него есть состояние, id и версия. Подписка на поле объекта возможна в API, но это фактически подписка на объект + фильтр.
Спасибо!
Про кэш. В LWW-решениях появление кэша на клиенте достаточно просто, он там и есть обычно. В нашем (CRDT) тоже. В OT решении — крайне маловероятно. OT крайне уязвимо к асинхронности, там комбинаторный взрыв получается и всякие каки. А оффлайновая работа «с кэша» — это максимально асинхронный сценарий.
В Google Docs приковыряли кэш как-то, но там, насколько понимаю, использовано другое решение, чем при онлайновой работе, плюс какие-то экстеншены нужно устанавливать в браузер. Внутрь не смотрел, но стойкий химический запах ощущается.
Так долго.
* скачал html
* пропарсил
* запустил js
* вытянул данные
* отрисовал
* засунул в DOM
Браузеры хорошо оптимизированы по линии скачал-показал, плюс пробежки туда-сюда это RTT.
Можете попробовать разобрать заметку про Causal Trees или посмотреть в блоге проекта пост про Лампортовы метки.
Что-то более подробное, с картинками, думаю, появится со временем тоже в блоге проекта.
Следите за @swarm_js.
Зависит от типа. Для простых объектов и ассоциативных массивов last write wins, где last определяется по timestamp. В Кассандре похожая схема (Лампортовская).
Для линейных структур (Vector, Text) используется merge по алгоритму Causal Trees. Результаты похожи на посимвольный 3-way merge (это чем патчи мержатся обычно в source control, только там всё построчно).
Ага, pouchdb.com ещё есть в ту же степь. Там всё state-based, если я не путаю, т.е. при конкурентной записи создаётся две версии объекта. Для нашего случая такой вариант не подходил, нам нужно было op-based — для больших объектов с кучей маленьких, часто конкурентных изменений. Плюс, у нас реальное время, там говорят задержка пара секунд. Немножко другой инструмент, короче.
И у меня в Плюсе полторы калеки.
Picasa была стартапом (Lifescape), как и Google Docs (Writely), Google Maps(Where 2 Tech) и многие другие их популярные сервисы, включая сам поиск. Стартап чуток к интересам пользователей.
Plus — это уже продукт большой компании, тут и политика и «маркетинг» и массивный нагон пользователей.
Всё закономерно.
Думаю, я один из этих 318млн как бы пользователей. Я даже как-то выложил на Plus сотни фоток (кнопочкой ошибся).
Chrome — это браузер, и тут разработчицкая машина Google показала себя с хорошей стороны. Но браузер — совсем другого типа продукт, он предназначен для одного пользователя, и если вы приводите такой контрпример, значит вы не поняли мою мысль.
Но обернуть запрос к БД в виде коллекции и слушать его — пока нельзя, но такой функционал в работе. Собственно, он неизбежно бекендо-зависимый, отдельная реализация для SQL, отдельная для Mongo, итд.
Первый уровень — op-based CRDT основа, там реализованы «лог», «операция», «объект».
Второй уровень — собственно типы данных, написанные поверх основы.
Ничто не мешает добавить класс ManualMap, который будет сохранять и явно указывать на конфликты. Сейчас реализован только самый простой ширпотреб.
Обещаем скоро исправиться.
2. Подписка идёт на объект, у него есть состояние, id и версия. Подписка на поле объекта возможна в API, но это фактически подписка на объект + фильтр.
Про кэш. В LWW-решениях появление кэша на клиенте достаточно просто, он там и есть обычно. В нашем (CRDT) тоже. В OT решении — крайне маловероятно. OT крайне уязвимо к асинхронности, там комбинаторный взрыв получается и всякие каки. А оффлайновая работа «с кэша» — это максимально асинхронный сценарий.
В Google Docs приковыряли кэш как-то, но там, насколько понимаю, использовано другое решение, чем при онлайновой работе, плюс какие-то экстеншены нужно устанавливать в браузер. Внутрь не смотрел, но стойкий химический запах ощущается.
* скачал html
* пропарсил
* запустил js
* вытянул данные
* отрисовал
* засунул в DOM
Браузеры хорошо оптимизированы по линии скачал-показал, плюс пробежки туда-сюда это RTT.
Что-то более подробное, с картинками, думаю, появится со временем тоже в блоге проекта.
Следите за @swarm_js.
Для линейных структур (Vector, Text) используется merge по алгоритму Causal Trees. Результаты похожи на посимвольный 3-way merge (это чем патчи мержатся обычно в source control, только там всё построчно).
www.dougengelbart.org/firsts/keyset.html
Т.е. можно было бы сказать, что их изобрели одновременно с мышью, если бы их не было и в телеграфном аппарате Бодо ещё веком раньше:
www.nadcomm.com/images/baudot1874ttysm.jpg
Всё новое — хорошо забытое старое.
тут кто-то явно говорит неправду
Picasa была стартапом (Lifescape), как и Google Docs (Writely), Google Maps(Where 2 Tech) и многие другие их популярные сервисы, включая сам поиск. Стартап чуток к интересам пользователей.
Plus — это уже продукт большой компании, тут и политика и «маркетинг» и массивный нагон пользователей.
Всё закономерно.
Chrome — это браузер, и тут разработчицкая машина Google показала себя с хорошей стороны. Но браузер — совсем другого типа продукт, он предназначен для одного пользователя, и если вы приводите такой контрпример, значит вы не поняли мою мысль.
Возможно, нужно пообщаться с гуру?