haskellwiki slow/unresponsive

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!
It is dead-simple to deploy a fast haskell web app, so haskell *might* have a chance at solving the problem, but likely it can be fixed much faster by doing a better job configuring the server or adding more resources. I think that security issues are a bit of a red herring. You can go through potential security issues one-by-one and basically make them impossible in a web/wiki framework (as we are doing in Yesod). Of course this is easier to do with a type system in Haskell. And of course some security is outside the scope of the software and needs to be established by procedure (admin server access should only be through ssh key, etc). 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. Even though it is may not be socially acceptable to state it, it is likely that gitit or any haskell library would be more secure in practice because it is more obscure. And the kind of security we really care about in the wiki- the wiki page content- can be easily replicated and restored. I definitely agree that the hard and boring part of switching to a haskell wiki is converting existing MediaWiki content and configuration to a new system- that would have to be investigated first. Unfortunately this is probably all bike-shedding and my original question of how can the community speed up the wiki hasn't been answered :) Greg Weber

On Mon, Jun 6, 2011 at 4:45 PM, Greg Weber
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. -- gwern http://www.gwern.net

+++ Gwern Branwen [Jun 06 11 17:47 ]:
On Mon, Jun 6, 2011 at 4:45 PM, Greg Weber
wrote: 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
participants (3)
-
Greg Weber
-
Gwern Branwen
-
John MacFarlane