Re: [O] [ANN] Editable HTML export of Org-mode files

[Eric Schulte]

Bastien <address@hidden> writes:

> Hi Eric,
>
> Eric Schulte <address@hidden> 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