Bastien <b...@gnu.org> writes: > Hi Eric, > > Eric Schulte <eric.schu...@gmx.com> 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
