सहयोगी संपादन के बारे में झूठ, भाग 1: ऑफलाइन संपादन के लिए एल्गोरिद्म

 (moment.dev)
2 पॉइंट द्वारा GN⁺ 2024-12-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2024 की शुरुआत में, Moment के मुख्य text editor में उपयोग के लिए एक collaborative editing system की जांच शुरू की गई। वर्तमान में कई एल्गोरिद्म यह दावा करते हैं कि वे online और offline editing की समस्या हल करते हैं। लेकिन वास्तविकता में यह पाया गया कि offline editing का अनुभव अच्छा नहीं है।
  • ऑफलाइन संपादन की समस्याएं
    • CRDTs और OT जैसे लोकप्रिय एल्गोरिद्म सीधे editing conflicts को गैर-सहज तरीके से हल करते हैं, जिससे users इसे data corruption के रूप में महसूस करते हैं।
    • Offline editing सीधे conflict की संभावना बढ़ा देता है, और ये एल्गोरिद्म offline editing के लिए उपयुक्त नहीं हैं।
  • उदाहरण: मामूली editing conflict
    • Alice और Bob offline स्थिति में document को संपादित करते हैं। Bob Color को Colour में बदलता है, और Alice पूरा text हटा देती है। बाद में online होने पर, इस conflict को हल करना पड़ता है।
    • ऐसे conflict आम हैं, और परिणामस्वरूप users को लगता है कि data खराब हो गया है।
  • एल्गोरिद्म की सीमाएं
    • Yjs, ShareJS, Peritext जैसे प्रोजेक्ट offline editing support का दावा करते हैं, लेकिन व्यवहार में बार-बार त्रुटियां होती हैं।
    • एल्गोरिद्म user intent नहीं जान सकते और character level पर काम करते हैं, इसलिए परिणाम के बारे में पर्याप्त गारंटी नहीं होती।
  • UI/UX समस्या की ओर बदलाव
    • केवल एल्गोरिद्म से इस समस्या को पूरी तरह हल नहीं किया जा सकता; इसे UI/UX समस्या के रूप में देखना चाहिए।
    • git जैसे document merge UI पहले से मौजूद हैं, और यह शोध किया जाना चाहिए कि इन्हें अधिक सुलभ और अधिक automated कैसे बनाया जाए।
    • कुछ शोधकर्ता इस समस्या पर UI/UX समस्या के रूप में ध्यान केंद्रित कर रहे हैं, और Ink & Switch का collaborative history research इसका एक उदाहरण है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-08
Hacker News राय

  • Eg-walker और ShareJS के लेखक ने उल्लेख किया कि रीयल-टाइम collaboration tools ऑनलाइन साथ काम करने में उपयोगी हैं, लेकिन offline editing या लंबी अवधि की branches में conflict markers जोड़ने और manual review करने का विकल्प होना चाहिए

    • Eg-walker algorithm हर उपयोगकर्ता की character-by-character edit tracking को store करता है और यह भी store करता है कि हर बदलाव कब हुआ, जिससे conflict ranges का पता लगाकर उन्हें दिखा सकने वाला CRDT बनाया जा सकता है
    • इस समस्या को दिलचस्प बताया गया है, और इस पर ज़ोर दिया गया है कि यह अभी तक हल नहीं हुई है, इसलिए इस पर और ध्यान देने की ज़रूरत है

  • CRDT का उपयोग करने वाली implementations की एक और समस्या infrastructure burden है

    • CRDT का उपयोग करने पर Redis या MyRocks जैसी चीज़ें इस्तेमाल करने की सलाह दी गई है, और RDBMS, खासकर Postgres, में backup न करने की सिफारिश की गई है

  • CRDT को note-taking software में integrate करने पर काम कर रहे एक उपयोगकर्ता को धन्यवाद दिया गया है

  • यह उल्लेख किया गया कि mechanical merge algorithms अलग-अलग तरह के conflicts में अलग performance दिखा सकते हैं, और CRDT यह तय नहीं कर सकता कि merged text वही है या नहीं जो उपयोगकर्ता चाहता था

    • Upwelling paper semantic conflicts और syntactic conflicts के बीच के अंतर को विस्तार से समझाता है
    • गंभीर collaboration असल में document review की समस्या है, और यह खासकर journalism और scientific publishing में महत्वपूर्ण है

  • collaborative text editing में इस्तेमाल होने वाले algorithms (CRDTs और OT) पर edit operations के execution और interaction को लेकर सख्त algebraic requirements होती हैं

    • server UX logic के अनुसार operations को process कर सकता है, और client optimistic editing की अनुमति देने के लिए rebase/prediction strategy का उपयोग कर सकता है

  • यह कहा गया कि mathematical, causal, और entropic conflicts की अवधारणाओं को semantic conflicts के साथ गड्डमड्ड कर दिया गया है

    • CRDTs में conflict-preserving class सबसे आशाजनक लगती है, और उपयोगकर्ता को conflicts को visual रूप से देख पाने में सक्षम होना चाहिए

  • AI का उपयोग करके merge की भविष्यवाणी करने की संभावना पेश की गई है

    • यह उल्लेख किया गया कि LLM लेखक के change sets को देखकर, edits के overlap होने या न होने के बारे में पूछकर, और बदलावों का क्रम तय करके 90% अच्छे नतीजे दे सकता है

  • CRDTs distributed data structures के लिए एक शानदार formal model हैं, लेकिन यह विचार समस्याग्रस्त है कि उन्हें हर conflict को अपने-आप resolve करना चाहिए

    • एक ऐसे model की ज़रूरत है जो conflicts को structural रूप में व्यक्त कर सके और उन्हें shared तथा collaborative तरीके से resolve कर सके
    • "Lazy Merging" नाम का structural conflict representation model विकसित किया गया है, जो mathematical approach के ज़रिए एक सरल conceptual model प्रस्तुत करता है

  • यह उल्लेख किया गया कि एक ही समय में कई entities का data पर अधिकार होना एक ऐसी समस्या है जिसका समाधान नहीं किया जा सकता

    • यह distributed systems से सीखा गया सबक है, और documents की distributed editing में यह साफ़ दिखाई देता है

  • यह उल्लेख किया गया कि 2009 में Git के changes को अपने-आप merge करने वाले algorithms पर बहुत चर्चा हुई थी, और Torvalds automatic merge की सीमाओं को लेकर संशय में थे

    • offline editing एक UI/UX समस्या है, और यह computing की उस समस्या से जुड़ी है जिसमें पुराने solutions को दोहराया जाता है
    • यह कहा गया कि text editing में offline collaborative merge प्रक्रिया के केंद्र में होना चाहिए, और MacWrite जैसे local maxima से बाहर निकलना मुश्किल है