Rockbox mail archiveSubject: Re: Straw poll on wiki replacement
Re: Straw poll on wiki replacement
From: Sam Kuper via rockbox-dev <rockbox-dev_at_cool.haxx.se>
Date: Tue, 30 Jun 2020 00:54:04 +0100
On Sat, Jun 27, 2020 at 06:08:36PM -0400, Solomon Peachy via rockbox-dev wrote:
> The Foswiki 1.1.x instance running on the rockbox www site has to go.
> There are many reasons, but the most serious/pressing reason is that
> its design flaws under even moderate load cause a DoS on the entire
> www server.
> The obvious path is to upgrade Foswiki 1.1.x to 2.x, but that requires
> creating a new 2.x site, manually importing/copying the old data over,
> then fixing everything that broke along the way.
> Given that level of effort, I'd rather ditch foswiki altogether, and
> replace it with sometihng that sucks less.
> The big question in my mind is if we replace it with another wiki
> engine or some sort of static site generated out of a git repo -- and
> ultimately that comes down to workflow.
> Do we care about having an interactive editor with changes going live
> instantly, or can it be done via git commits with the live site
> auto-updated as part of a commit hook?
My voice should not count for much, because I've only contributed a
couple of miniscule commits to Rockbox, but: I think an asynchronouse
DVCS (e.g. Git) would be preferable to a synchronous web interface.
The synchronous web interface typical of wiki editing has several
- impractical for a user to make edits when offline;
- linear history, which means:
- no branches for trying out new approaches;
- no review queue *OR ELSE* updates pending review typically hold up
- needs a web server running a scripting language (vulnerable; resource
intensive) and a database server running an RDBMS (likewise);
- needs security patches to be applied promptly, else server likely to
be exploited by bots (to steal user credentials, or serve malware,
- users need to register an account;
- susceptible to spam (anyone who has run a web-facing MediaWiki
instance will have experience of this).
All those problems can be avoided by using a DVCS and a static site
> But a static site is arguably not as contributor-friendly as an
> interactive wiki page editor, requiring git (&| gerrit access),
> definitely a higher bar.
I guess you're right that using Git is a higher bar than editing a wiki,
but in practice (at least, for basic Git usage) the difference may be
immaterial. I'd wager that the demographic willing to edit wiki pages
overlaps quite widely with the demographic willing to send Git patches.
> All else being equal I'd prefer a static site generator, especially
> with my administrative hat firmly affixed.
> (Oh, one other thing -- I want things to remain self-hosted, so moving
> to something like the github wiki is off the table as far as I'm
I support you on these fronts.
> Anyone else have thoughts on a path forward?
I would welcome a static site generator. I don't have strong feelings
about which particular one, except that it should be:
- free (as in freedom) under an FSF- and OSI-approved license;
- programmed in a language with which you (and other Rockbox developers)
are comfortable, in case it needs patching or tweaking to taste;
- able to generate web pages that don't rely on the visitor using
"single-page application" in the vein of AngularJS);
- well-maintained via sane procedures (Git repo; mailing list; ...), or
else so stable that it doesn't need this;
- able to ingest reasonably sane lightweight markup (e.g. Org,
ReStructuredText, AsciiDoc) as its main form of input;
- preferably able to ingest tables in that same lightweight markup
language, so that they don't have to be manually marked up as HTML.
Whatever you decide, good luck with the transition and thank you again
for maintaining Rockbox.
-- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.Received on 2020-06-29