From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Fran=C3=A7ois_Pinard?= Subject: colorg: A few more thoughts Date: Mon, 14 Jan 2013 02:09:34 -0500 Message-ID: <86bocsp7f5.fsf@iro.umontreal.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:34533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TueDe-0001Sk-L3 for emacs-orgmode@gnu.org; Mon, 14 Jan 2013 02:12:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TueAp-0005OJ-UF for emacs-orgmode@gnu.org; Mon, 14 Jan 2013 02:09:41 -0500 Received: from 206-248-137-202.dsl.teksavvy.com ([206.248.137.202]:63704 helo=mercure.bureau.ubity.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TueAp-0005OA-P9 for emacs-orgmode@gnu.org; Mon, 14 Jan 2013 02:09:35 -0500 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi, Orgers! Here are some development news about ColOrg, which is a tool meant for real-time collaborative edition for Org files. I pushed a bit on the project this weekend, but now, job duties might force me to delay further work until next weekend. I'm not done yet with the initial writing, it is all very broken, many things need to be completed before usability. Yet, a bit everything starts to move, I even got the encouraging proof that some communication occurs between Emacs and the ColOrg server. :-) The tool is likely to be surprisingly small, both on the client side (in Emacs Lisp) and the server side (in Python). Usage is going to be simple and crude at start. We minimally do not need much: a toggle command to put any Emacs buffer under ColOrg, and a few initial questions (most of them may be spared), and that's it. A newly created resource gets transparently uploaded to the server for sharing, an existing resource is downloaded when associated with an empty buffer. Separate buffers may be associated to separate (or even the same) resource, ColOrg is designed to multiplex and manage them. Responsivity (typing speed) might be reasonable enough. I stuffed a few stub routines with delays, to get an idea of how it would go. I've given some good thought to the rewriting of the operational transforms, this is the main missing part on the Python side. I think I have a dependable but inefficient solution in head, that would admit hairy optimization. The ColOrg Wiki would be a nice place to receive a description of the problem and chosen solutions. To be done later. Many details remain to be addressed. For example: how to interface with Undo within Emacs? It has incidence on the design of the protocol. My current choice is either to postpone and let every change be separate, or collapse outside changes from many users, arriving at once, into a single Undo step. Have fun! For now, sleep time! Fran=C3=A7ois