[Pdx-pm] TWiki as substitute for kwiki?

benh ben.hengst at gmail.com
Tue Mar 27 20:11:17 PDT 2007

well... why not have a svn driven flat text system? I havent dug with
the back end of any wiki so I dont know if the tend to be flat files
or some DB (well it sounds like MW is mysql). Though then this make me
just think that we could just svn pod up and have one of the pod2html
modules run as a hook script... tada!... not purty, but conflicts
would be resolved... and you could still use vim...

* ehh * just an idea.

On 3/27/07, Eric Wilhelm <scratchcomputing at gmail.com> wrote:
> # from Thomas J Keller
> # on Tuesday 27 March 2007 01:36 pm:
> >I had the impression Eric was wondering if there wasn't another
> >approach to "staying connected" other than a wiki. He mentioned
> >Combust, I think. (?)
> >.. I like wikis myself, but many people find them to much of a
> >nuisance to mess with, so I haven't gotten get as much input using
> >them as I would like.
> I'm in that other crowd.  I haven't found a single web app that I like
> yet.  I like the idea of wiki, just hate using a browser as an editor.
> (Hmm, the verbs inside those nouns might hold a clue as to why...)
> Possibly kwiki with decent security and spam prevention and a RESTful
> API would enable a thick-client mode.
> But, then I wonder why we don't just use subversion.  (And, honestly, I
> don't like to edit much of anything outside of vim.)  If the layout
> engine could play nice with dotReader, a plugin might be able to serve
> as a client-side preview tool.  That, or I could get over my desire to
> preview and just write everything in unmarked text.
> And, of course I would love to see *any* wiki *handle* conflict
> resolution.  After a few preview+scroll+scroll+edit+scroll+preview
> cycles, being told that someone else has changed the page since I
> started and not having any straightforward way to cherry-pick the
> changes is enough to make me just close the window and forget about it.
> --Eric
> --
> Don't worry about what anybody else is going to do. The best way to
> predict the future is to invent it.
> --Alan Kay
> ---------------------------------------------------
>     http://scratchcomputing.com
> ---------------------------------------------------
> _______________________________________________
> Pdx-pm-list mailing list
> Pdx-pm-list at pm.org
> http://mail.pm.org/mailman/listinfo/pdx-pm-list


More information about the Pdx-pm-list mailing list