On 02/22/2010 02:28 PM, Caleb James DeLisle wrote: > Guests should be allowed to comment on a page but we still want to avoid > automated > comment adding and captcha is a solution which already exists. > > If a captcha is displayed on each comment form which shows at the bottom of > each page > then each page load will require the generation of a captcha which will hurt > performance. > > A. > When the user is anonymous, don't show the comment form, instead show a link > "Add Comment" and load the form and image through ajax. > This would not be a major change since anonymous users currently don't see > the comment form. > > B. > Display the form but strip the 'Add Comment' button and force the user to > preview the > comment and load the image with the preview button. Of course the behavior > must be > different when users don't have Javascript and they are viewing the comments > through > "?viewer=comments" so there would have to be some means of detecting how > commentsinline > was being loaded. > > > In order to keep the core from becoming dependent on the captcha module, the > commentadd > action will have to be duplicated in commentinline.vm I see no other way > around it. > > Any other ideas?
I don't like either of these approaches, mainly because it involves an additional step. We're making the process cumbersome for the user just because we're trying to mask performance issues. No other public site I've seen does it this way, and perhaps there's a reason. A guest that wants to comment is (most times) doing an unpaid favor to the author. If the author makes this process difficult, then the user will take his comment away and find another site. And we don't want that. First, I don't agree that guests should have the right to comment by default. The default rights should be the same as they are now. And it is easy to enable comments for guests. The only thing that would need to change is that when guests can comment, beside the new comment form the captcha image should be displayed. Is there really a performance issue? Our target market (intranets) don't need this at all, since all users must be logged in to even view a page. There are very few public sites based on XWiki that allow guest commenting, but we still should care about those. So, there is a performance problem, but it should be handled differently. On a really busy server, where clustering is needed, then the best approach would be to have a distinct server for generating images, which should be used by all the XWiki servers. One step would be to make sure that this use case is supported by our captcha module. If the image generation process is inside the wiki server, then there are other few improvements that could be implemented. Here's a possible approach: - the images are not generated synchronously on demand, but are generated in a separate thread and pushed into a pool of tests (image + solution); I'm thinking a queue with a fixed size QS and blocking pull/push - when a thread needs a new image it takes it from the pool (blocking until an image is generated if none is available) - images are not automatically consumed once used, they are pushed back in the queue, except if: a) it was solved b) it was attempted NA times without being solved c) it was displayed ND times without being attempted/solved If QS is large enough, users won't notice that the same image is used. This will help reduce the load since not all requests will require a new image, and the proper configuration would still make this effective. Of course, QS, NA, ND should all be easily configurable. Some defaults from the top of my head: 300, 3, 10. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
