From: Eric Schulte <eric.schulte@gmx.com>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org, Rasmus <rasmus@gmx.us>
Subject: Re: [ANN] Editable HTML export of Org-mode files
Date: Wed, 15 Aug 2012 09:31:57 -0600 [thread overview]
Message-ID: <87pq6sb28i.fsf@gmx.com> (raw)
In-Reply-To: <87vcglywp3.fsf@gnu.org> (Bastien's message of "Tue, 14 Aug 2012 23:45:28 +0200")
Bastien <bzg@gnu.org> writes:
> Hi Eric,
>
> Eric Schulte <eric.schulte@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
next prev parent reply other threads:[~2012-08-15 16:11 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-13 22:28 [ANN] Editable HTML export of Org-mode files Eric Schulte
2012-08-14 7:44 ` Bastien
2012-08-14 9:40 ` Rasmus
2012-08-14 10:01 ` Bastien
2012-08-14 12:56 ` Eric Schulte
2012-08-14 21:45 ` Bastien
2012-08-15 15:31 ` Eric Schulte [this message]
2012-08-15 3:25 ` Eric Abrahamsen
2012-08-15 15:17 ` Eric Schulte
2012-08-15 23:51 ` Eric Schulte
2012-08-16 5:08 ` Eric Abrahamsen
2012-08-16 6:45 ` Eric Schulte
2012-08-16 7:27 ` Eric Abrahamsen
2012-08-16 13:36 ` Eric Schulte
2012-08-16 14:41 ` Eric Abrahamsen
2012-08-16 15:08 ` Eric Schulte
2012-08-16 2:06 ` Ista Zahn
2012-08-16 6:31 ` Eric Schulte
2012-08-16 15:58 ` Ista Zahn
2012-08-16 16:36 ` Eric Schulte
2012-08-16 17:44 ` Achim Gratz
2012-08-16 20:05 ` Eric Schulte
2012-08-16 19:43 ` Ista Zahn
2012-08-16 20:11 ` Eric Schulte
2012-08-16 20:50 ` Ista Zahn
2012-10-02 5:23 ` Eric S Fraga
2012-10-05 3:23 ` Eric Schulte
2012-10-21 18:27 ` Simon Thum
2012-10-22 20:38 ` Eric Schulte
2012-10-24 19:19 ` Simon Thum
2012-10-28 15:19 ` Eric Schulte
2012-10-28 15:35 ` Simon Thum
2012-10-29 8:29 ` Nitin Agarwal
2012-10-30 9:37 ` Nitin Agarwal
2012-10-30 16:56 ` Eric Schulte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pq6sb28i.fsf@gmx.com \
--to=eric.schulte@gmx.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).