From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [ANN] Editable HTML export of Org-mode files Date: Wed, 15 Aug 2012 09:31:57 -0600 Message-ID: <87pq6sb28i.fsf@gmx.com> References: <87pq6ua0kk.fsf@gmx.com> <87393p7qvy.fsf@pank.lan> <87lihhrdvy.fsf@gnu.org> <87a9xx7gtq.fsf@gmx.com> <87vcglywp3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:41534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1gBi-0002mL-W5 for emacs-orgmode@gnu.org; Wed, 15 Aug 2012 12:11:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1gBh-0003aN-IJ for emacs-orgmode@gnu.org; Wed, 15 Aug 2012 12:11:18 -0400 Received: from mailout-us.gmx.com ([74.208.5.67]:49772) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1T1gBh-0003YB-Bt for emacs-orgmode@gnu.org; Wed, 15 Aug 2012 12:11:17 -0400 In-Reply-To: <87vcglywp3.fsf@gnu.org> (Bastien's message of "Tue, 14 Aug 2012 23:45:28 +0200") 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: Bastien Cc: emacs-orgmode@gnu.org, Rasmus Bastien writes: > Hi Eric, > > Eric Schulte writes: > >> With respect to security, elnode has a simple authentication system >> which seems to work well in my local trials. It has no forms for >> setting passwords online, so users would have to generate a hash of >> their password locally, and then send the hash to someone who would >> manually add it to the elnode authentication database on orgmode.org. >> >> During authentication the hashed password is sent in plain text, so we >> would need to run the elnode server behind an https proxy server. I >> don't think this would be difficult to implement and is a good idea for >> any system with authentication. > > Thanks for those details. > >> With respect to integration with the existing Worg, this system should >> work well in concert with the git backend. Git could still be used for >> offline edits as it is currently. The org-ehtml server could be >> configured to commit all web edits to git. A conflict checker would be >> needed, which could be added to the `org-ehtml-before-save-hook'. > > I think a page should be locked when a user is editing it through > org-ehtml.el. This would prevent conflicts from concurrent editing > from the web. > > As for conflicts between the .org to be written (from org-ehtml) and > the .org that might have been pushed trough git, what would be the > behavior? Discard this edit? Use org-merge-driver to help resolve > the conflict? Let the user download the .org he has been editing, > so that his changes are not lost? > I haven't given this much thought, but my first instinct is to avoid any use of locking. I think the conflict resolution model used by version control systems could also be appropriate here. Namely, the first to commit an edit has their edit applied, and any subsequent out-of-date edits are merged. - if the backend VC system is able to automatically merge the edit, then this will be done automatically. The probability of a successful merge becomes more likely if the new org-merge engine is used by the backing VC system. - if such a merge is not possible, then the edited version should be saved in some way. maybe this data should be presented to the user in a plain text block or as a file download (depending on edit size). The user could then refresh the org page to get the new version and manually incorporate their edit. - if at some point in the hazy distant future someone builds a simple elnode web interface to ediff, then that could be used to perform live merges of files. Such a system would boast better conflict handling than any existing wiki system of which I'm currently aware. > > This is still quite unclear to me. > > In any case, we should first try this on a prototype for a while and > see if this is robust enough. I absolutely agree, this is not yet ready for Worg. After we figure out good answers to the above we can try a test run in a sandbox, and then possibly migrate to Worg only after we're convinced this is stable. I view org-ehtml as an opportunistic integration of a confluence of developments in elnode and org-element. While I think it is an elegant design and has a lot of potential I wouldn't call it a production-ready system. Thanks -- Eric Schulte http://cs.unm.edu/~eschulte