doc/todo/applydiff_plugin.mdwn

   1 [[!tag wishlist]]
   2
   3 [[!toc ]]
   4
   5 Summary
   6 =======
   7
   8 Allow a user to apply an arbitrary diff, in order to modify a given
   9 page (or, even better, a given set of pages).
  10
  11 Rationale
  12 =========
  13
  14 To edit intensively an ikiwiki-powered website can quickly get
  15 annoying for anybody meeting enough of the following conditions:
  16
  17 * living mainly offline
  18 * having no commit access to the RCS backing up the site (BTW, please
  19   note I can send my ssh public key to anyone who asks for, free of
  20   charges)
  21 * hating web-browsers and despising textareas
  22 * loving in his/her own preferred `$EDITOR`
  23
  24 ... and when one gathers all of these defaults, she/he is on her/his
  25 way to get mad. Soon.
  26
  27 Before it's too late, some dareful ones dream of the following
  28 playflow:
  29
  30 1. Go online.
  31 1. Update local working copy.
  32 1. Go offline.
  33 1. `$EDITOR` : write, report, answer, propose
  34 1. Go online.
  35 1. Update local working copy (and optionally fix conflicts between
  36    local changes and remote ones).
  37 1. Generate a diff.
  38 1. Use a web-browser to paste the diffs (or better, upload them into
  39    a form) somewhere on the wiki, and click "Apply".
  40 1. git pull (to reflect locally the fact that the diff has been
  41    applied to the remote repo)
  42 1. Go offline.
  43
  44 (This is for sure a bit theoretical: the ones who dream of this would
  45 actually insert various steps about branching, merging and rebasing
  46 random stuff.)
  47
  48 Design
  49 ======
  50
  51 This has to be thought very carefully, to avoid one to apply diffs to
  52 pages he/she is not allowed to edit. Restricting a given diff to
  53 modify only *one* page may be easier.
  54
  55 Implementation
  56 ==============
  57
  58 Also see [[joey]]'s idea on [[users/xma/discussion]], to allow (filtered) anonymous push to this wiki's repository.
  59
  60 > Ideally the filtering should apply the same constraints on what's pushed
  61 > as are applied to web edits. So locked pages can't be changed, etc.
  62 >
  63 > That could be accomplished by making the git pre-receive hook be a
  64 > ikiwiki wrapper. A new `git_receive_wrapper` config setting could cause
  65 > the wrapper to be generated, with `$config{receive}` set to true.
  66 >
  67 > When run that way, ikiwiki would call `rcs_receive`. In the case of git,
  68 > that would look at the received changes as fed into the hook on stdin,
  69 > and use `parse_diff_tree` to get a list of the files changed. Then it
  70 > could determine if the changes were allowed.
  71 >
  72 > To do that, it should perhaps first look at what unix user received the
  73 > commit.  That could be mapped directly to an ikiwiki user. This would
  74 > typically be an unprivelidged user, but you might also want to set up
  75 > separate users who have fewer limits on what they can push. OTOH, I'm not
  76 > sure how to get this info in an ikiwiki wrapper.. the real and effective
  77 > gid are already trampled. So maybe leave this out and always treat it as
  78 > an anonymous edit from a non-logged in user?
  79 >
  80 > Then it seems like it would want to call `check_canedit` to test if an
  81 > edit to each changed page is allowed. Might also want to call
  82 > `check_canattach` and `check_canremove` if the attach and remove plugins
  83 > are enabled. All three expect to be passed a CGI and a CGI::Session
  84 > object, which is a bit problimatic here. So dummy the objects up? (To call
  85 > `check_canattach` the changed attachment would need to be extracted to a
  86 > temp file for it to check..)
  87 >
  88 > If a change is disallowed, it would print out what was disallowed, and
  89 > exit nonzero. I think that git then discards the pushed objects (or maybe
  90 > they remain in the database until `git-gc` .. if so, that could be used
  91 > to DOS by uploading junk, so need to check this point).
  92 >
  93 > Also, I've not verified that the objects have been recieved already when
  94 > whe pre-receive hook is called. Although the docs seem to say that is the
  95 > case. --[[Joey]]