실시간 협업 편집 - 어떻게 작동합니까?

실시간 협업 편집 - 어떻게 작동합니까?

문서를 거의 실시간으로 공동 편집하고 싶은 응용 프로그램을 작성하고 있습니다(Google Documents 스타일 편집과 매우 유사함).

커서 위치를 추적하는 방법은 알고 있습니다. 간단합니다.데이터베이스에 저장할 수 있는 현재 사용자 ID, 파일 이름, 행 번호 및 행 번호를 사용하여 서버를 폴링하면 이 폴링 요청의 반환 값이 다른 사용자의 커서 위치입니다.

제가 할 수 있는 방법은 커서가 떨어져 나가지 않고 완전히 새로고침되지 않도록 문서를 업데이트하는 것입니다. 제 목적에 따라서는 너무 느릴 수 있기 때문입니다.

이것은 Google Chrome, 특히 Firefox에서만 작동해야 합니다.다른 브라우저는 지원하지 않습니다.

여러 피어에서 공동 편집을 병합하기 위해 백그라운드에서 사용되는 알고리즘을 운영 변환이라고 합니다.하지만 구현은 간단하지 않습니다.

도움이 되는 링크에 대해서는, 이 질문도 참조해 주세요.

실시간 공동 편집을 수행하려면 몇 가지 사항이 필요합니다.여기서의 다른 답변의 대부분은 문제의 한 가지 측면, 즉 분산 상태(공유-변환 상태)에만 초점을 맞추고 있습니다.OT(Operational Transformation), CRDT(Conflict-Free Replicated Data Type), 차등 동기화 및 기타 관련 기술은 모두 실시간에 가까운 분산 상태를 실현하기 위한 접근 방식입니다.대부분은 최종적인 일관성에 초점을 맞추고 있으며, 이를 통해 각 참가자 상태의 일시적인 분기가 허용되지만 편집이 중지될 때 각 참가자 상태가 최종적으로 수렴될 수 있습니다.그 외의 회답에서는, 이러한 테크놀로지의 몇개의 실장에 대해 언급하고 있습니다.

단, 변경 가능한 상태를 공유한 후에는 적절한 사용자 경험을 제공하기 위해 몇 가지 다른 기능이 필요합니다.이러한 추가 개념의 예는 다음과 같습니다.

• 아이덴티티:어떤 사람들과 협업하고 있는지.
• 존재감:현재 '여기에서' 편집 중인 사용자.
• 커뮤니케이션:사용자가 액션을 조정할 수 있는 채팅, 오디오, 비디오 등
• 콜라보레이티브 큐잉:다른 참가자가 무엇을 하고 있는지 및/또는 무엇을 하려고 하는지를 나타내는 기능.

공유 커서 및 선택 항목은 협업 큐잉(Collaboration Awareness)의 예입니다.이러한 정보는 사용자가 다른 참가자의 의도와 가능한 다음 행동을 이해하는 데 도움이 됩니다.원래 포스터는 부분적으로 공유 가변 상태와 협업 큐잉 사이의 상호작용에 대해 묻고 있었다.일반적으로 문서에서 커서 또는 선택 항목의 위치는 문서 내의 위치를 통해 설명되므로 이 작업은 중요합니다.이 문제는 커서 위치(예:)가 문서의 컨텍스트에 따라 다르다는 것입니다.커서가 인덱스 37에 있다고 하면 보고 있는 문서의 문자 37을 의미합니다.현재 가지고 계신 문서는 편집 내용이나 다른 사용자의 편집 내용 때문에 제 문서와 다를 수 있으며, 따라서 문서의 색인 37이 올바르지 않을 수 있습니다.

따라서 커서 위치를 배포하기 위해 사용하는 메커니즘은 공유 가변 상태에 대한 동시 제어 기능을 제공하는 시스템의 메커니즘에 통합되어 있거나 최소한 인식되어 있어야 합니다.오늘날 당면 과제 중 하나는 OT/CRDT, 양방향 메시징, 채팅 및 기타 라이브러리가 많지만 통합되지 않은 격리된 솔루션이라는 것입니다.이로 인해 우수한 사용자 경험을 제공하는 최종 사용자 시스템을 구축하는 것이 어려워지고 개발자가 해결해야 할 기술적 문제가 종종 발생합니다.

최종적으로 효과적인 실시간 협업 편집 시스템을 구현하기 위해서는 이러한 모든 측면을 고려해야 합니다.이력, 인가, 애플리케이션 수준의 경합 해결 및 기타 많은 측면에 대해서는 논의조차 하지 않았습니다.사용 사례에 맞는 방식으로 이러한 개념을 지원하는 기술을 구축하거나 찾아야 합니다.그런 다음 통합해야 합니다.

좋은 소식은 공동 편집을 지원하는 애플리케이션이 점점 더 인기를 끌고 있다는 것입니다.이를 뒷받침하는 기술이 성숙해지면서 매달 새로운 기술을 이용할 수 있게 됐다.Firebase는 이러한 개념의 많은 부분을 사용하기 쉬운 API로 정리하려고 시도한 최초의 솔루션 중 하나입니다.새로운 사용자 컨버전스(완전 공개, 저는 Convergence Labs의 설립자)는 이러한 협업 편집 기능의 대부분을 지원하고 실시간 협업 편집 앱 구축에 소요되는 시간, 비용 및 복잡성을 크게 줄일 수 있는 올인원 API를 제공합니다.

여기에는 반드시 xmpp나 wave가 필요하지 않습니다.infinote라고 불리는 오픈 소스 구현 작업의 대부분은 이미 jinfinote(https://github.com/sveith/jinfinote)에서 수행되었습니다.Jinfinote는 최근 python(https://github.com/phrearch/py-infinote))으로 포팅되어 동시성과 문서 상태를 중앙에서 처리했습니다.저는 현재 hwios 프로젝트(https://github.com/phrearch/hwios),에서 웹소켓과 json 트랜스포트 둘 다 사용하고 있습니다.이러한 종류의 어플리케이션에는 폴링을 사용하지 않는 것이 좋습니다.또한 xmpp는 불필요하게 일을 복잡하게 만드는 것 같습니다.

이 질문을 받고 좀 더 신중하게 검색해본 결과, 가장 좋은 스탠드아론 어플리케이션은 서버 측에서 Node.js를 사용하는 JS 브라우저 앱으로 실행되는 Etherpad가 될 것 같습니다.그 배후에 있는 테크놀로지는 운용상의 변혁이라고 불립니다.

Etherpad는 원래 구글에 의해 인수되어 구글 웨이브에 통합되었지만 실패한 꽤 무거운 어플리케이션이었다.이 코드는 오픈 소스로 공개되었고, 이 기술은 현재 "Etherpad"로 이름 붙여진 Etherpad Lite용 Javascript로 다시 쓰여졌다.일부 Etherpad 기술은 Google Docs에도 통합되었을 것입니다.

Etherpad 이후 이 기술에는 다양한 버전이 있으며, 특히 웹 앱에 직접 통합할 수 있는 Javascript 라이브러리도 있습니다.

• Share JS
• 동작하지 않다

저는 Meteor 앱에 실시간 에디터를 직접 추가하기 위한 Meteor-sharejs 패키지를 관리하고 있습니다.IMHO는 두 세계 모두 최고입니다.

Gintautas가 지적한 바와 같이 이는 운영상의 혁신에 의해 이루어집니다.제가 알기로는, 이 기능에 대한 연구 개발의 대부분은 지금은 사라진 Google Wave 프로젝트의 일환으로 이루어졌으며, Wave Protocol로 알려져 있습니다.다행히 Google Wave는 공개되어 있기 때문에 http://code.google.com/p/wave-protocol/에서 좋은 코드 샘플을 얻을 수 있습니다.

Google Docs 팀은 실시간 공동 작업이 어떻게 이루어졌는지 사례 연구를 조금 했지만 블로그 엔트리를 찾을 수 없었습니다.

위키피디아 페이지에는 괜찮은 내용이 몇 가지 있습니다.http://en.wikipedia.org/wiki/Collaborative_real-time_editor

저는 최근에 여러분이 달성하고자 하는 것을 보여주는 실제 사례를 담은 저장소를 공개했습니다.

https://quill-sharedb-cursors.herokuapp.com

이는 백엔드로 작동하는 ShareDB(OT)와 프런트엔드의 Quill 리치 텍스트 편집기를 기반으로 합니다.

기본적으로 이 모든 것을 더 많은 코드로 연결하여 커서를 그릴 수 있습니다.코드를 이해하고 특정 솔루션에 복사하는 것은 매우 간단해야 합니다.

노력하는데 도움이 되길 바랍니다.

언급URL : https://stackoverflow.com/questions/5086699/real-time-collaborative-editing-how-does-it-work