Re: [Haskell-cafe] haskellwiki slow/unresponsive
+++ Gwern Branwen [Jun 06 11 17:47 ]: On Mon, Jun 6, 2011 at 4:45 PM, Greg Weber g...@gregweber.info 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskellwiki slow/unresponsive
On Mon, Jun 6, 2011 at 4:45 PM, Greg Weber g...@gregweber.info 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. -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskellwiki slow/unresponsive
I have been trying to make a few edits to the haskell wiki and find it an excruciating process when I press save and then have to wait a long time to see if the save will go through. I just clicked on the introduction page and it may have took an entire minute to load. Can we put at the top: this wiki written in php, not haskell! Seriously though, the wiki has performed poorly for a long time now. It gives a bad impression to newcomers and deters contributions. Can I (and others!) donate money so someone can make the wiki responsive? Thanks, Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskellwiki slow/unresponsive
This is a bit of a tangent, but has anyone developed wiki software in Haskell? If anyone is working on this or interested in working on it, I'd like to help. I've built simple wiki applications with Python web frameworks and have been looking for a good project to start learning one of the Haskell web application frameworks. Eventually it'd be nice to proudly advertise all the prominent Haskell community pages as being powered by Haskell. Thanks! Eric On Fri, Jun 3, 2011 at 12:50 PM, Greg Weber g...@gregweber.info wrote: I have been trying to make a few edits to the haskell wiki and find it an excruciating process when I press save and then have to wait a long time to see if the save will go through. I just clicked on the introduction page and it may have took an entire minute to load. Can we put at the top: this wiki written in php, not haskell! Seriously though, the wiki has performed poorly for a long time now. It gives a bad impression to newcomers and deters contributions. Can I (and others!) donate money so someone can make the wiki responsive? Thanks, Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskellwiki slow/unresponsive
On 3 June 2011 22:17, Eric Rasmussen ericrasmus...@gmail.com wrote: This is a bit of a tangent, but has anyone developed wiki software in Haskell? 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskellwiki slow/unresponsive
On 4 June 2011 06:17, Eric Rasmussen ericrasmus...@gmail.com wrote: This is a bit of a tangent, but has anyone developed wiki software in Haskell? http://hackage.haskell.org/package/gitit -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskellwiki slow/unresponsive
On Fri, Jun 3, 2011 at 4:17 PM, Eric Rasmussen ericrasmus...@gmail.com wrote: This is a bit of a tangent, but has anyone developed wiki software in Haskell? 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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! On Fri, Jun 3, 2011 at 3:11 PM, Gwern Branwen gwe...@gmail.com wrote: On Fri, Jun 3, 2011 at 4:17 PM, Eric Rasmussen ericrasmus...@gmail.com wrote: This is a bit of a tangent, but has anyone developed wiki software in Haskell? 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe