_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
They have[1][2], but there's always room for more.
[1]: http://hackage.haskell.org/package/gitit
[2]: http://hackage.haskell.org/package/Flippi
http://hackage.haskell.org/package/gitit
--
Ivan Lazar Miljenovic
Ivan.Mi...@gmail.com
IvanMiljenovic.wordpress.com
Gitit is the most developed one, and it's been suggested in the past
that hawiki move over. It's not a good idea for a couple reasons,
which I've said before but I'll repeat here:
1. Performance; there have been major issues with the Darcs backend,
though mostly resolved, and we don't know how well the Git backend
would scale either. Gitit has mostly been used with single-users (how
I use it) or projects with light traffic (wiki.darcs.net). I don't
know why hawiki is slow, but whatever it is is probably either
hardware or configuration related - MediaWiki after all powers one of
the most popular websites in the world.
2. Security; there have been big holes in Gitit. Some of it is simple
immaturity, some of it due to the DVCS backends. Where there is one
hole, there are probably more - if there aren't holes in the Gitit
code proper, there probably are some in Happstack. There's no reason
to think there aren't: security is extremely hard. And in that
respect, Mediawiki is simply much more battle-tested. (Most popular
websites in the world, again, and one that particularly invites abuse
and attack.)
3. The existing hawiki content is Mediawiki centric, relying on
templates and MW syntax etc. Templates alone would have to be
implemented somehow, and Pandoc's MW parser is, last I heard, pretty
limited.
Gitit is great for what it is, and I like using it - but it's not
something I would rely on for anything vital, and especially not for
something which might be attacked. (This isn't paranoia; I deal with
spammers every day on hawiki, and c.h.o was rooted recently enough
that the memory should still be fresh in our collective minds.)
--
gwern
http://www.gwern.net
Those are definitely valid concerns. Has anyone made a wiki-like site with
Yesod? I hadn't heard of Yesod until I joined this mailing list, but I've
seen quite a bit of buzz around it since then. If a large enough chunk of
the community is backing a framework and focusing on making it secure and
reliable, then it should be possible to build applications with it (wikis,
blogs, etc.) that draw on the framework's strength and security. You may
still have security issues, but if they're continually addressed and
maintained at the framework level it benefits everyone building applications
on top of that framework. I'm still relatively new to the Haskell community
so I apologize if much of this has been addressed before!
> Gitit uses darcs or git to store data, but through the command line
> interfaces. Unfortunately to my knowledge darcs does not expose a library
> interface. Gitit could be made faster and more secure by interfacing with
> libgit2.
Darcs does export a library and pretty much has ever since I first
cabalized it; see http://hackage.haskell.org/package/darcs for the
module listings. It's not a very useful API, however. I don't know how
to use it, and John doesn't know how to use libgit2, I suspect.
I haven't had much time to work on gitit + filestore lately, and I'll
have even less in the future. I'd rather focus my programming time on
pandoc. So I'd be game if someone wanted to take the project in a new
direction.
Looks as if there are already Haskell bindings to libgit2:
http://hackage.haskell.org/packages/archive/hlibgit2
A first step might be rewriting filestore to use libgit and libdarcs
instead of shelling out to the programs.
It also might be nice to create a filestore instance that uses a
persistent in-memory datastore like acid-state; this would be very fast,
and appropriate for a wiki (like hawiki) with mostly textual content.
I would also not object to a rewrite using Yesod -- the type-safe URLs
and the support for subsites would both be really useful in gitit.
John