Re: [cgiapp] Future of the wiki
Hi Mark On Sat, 2010-02-27 at 23:58 -0500, Mark Rajcok wrote: I don't think we should write a CGI-App-based wiki for the following reasons: Agreed. In summary, I'd rather switch to a more feature rich wiki (I don't care if it's written in Perl), and have all of the people who were willing to spend time writing a new CGI-App-based wiki instead spend their time writing a more useful reference app, or write some useful pages on the new wiki! I'm with you. It's a monumental job to write a wiki, and it's just reinventing the wheel. See e.g. http://foswiki.org/ for a sophisticated Perl-based wiki. I've just installed it at home, in order to teach myself how to install it on a VPS (i.e. hosted) web site. -- Ron Savage r...@savage.net.au http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
My 2 cents about the CGI-App wiki. I recently halted development on my app to learn about Unicode and UTF-8 (and I guess I also ended up learning about character encodings in general -- wow, did I miss some important training somewhere in my past). As usual, I found many good discussions in the CGI-App mail archive (thank you all) but nothing on the wiki. I decided I would spend a few hours and put a summary together of what I learned. I decided against putting it on the CGI-App wiki for the following reasons (i.e., lack of features): 1. no automatic table of contents generation (visit http://en.wikibooks.org/wiki/Perl_Programming/Unicode_UTF-8 and you'll see why this was important) 2. no ability to edit small sections of a page Some other nice features about wikibooks - source code highlighting - discussion page (I did put a link on the CGI-App wiki to the Wikibooks doc, so if someone searches for Unicode or UTF-8, something will show up.) I don't think we should write a CGI-App-based wiki for the following reasons: 1. It will never have the feature set of other wikis, which means that probably no one else would ever use this wiki except us. 2. Regarding it would be a good CGI-App sample app for people to look at and learn from -- there are already some sample apps out there that people can look at. I don't think we need a wiki sample reference app. If we're going to collectively build a new sample/reference app, how about something more interesting -- like a social networking site/framework. 3. It won't see the light of day for months... this is the 2nd or 3rd time this was discussed, and I didn't see any marching orders materialize from this thread yet... Regarding the current wiki, I think a few simple changes would make it look a lot better: - set the default font size (to something smaller) - use something other than verdana for the headings (that font looks bad large) - lighten the dark black border around the main content -- it is too dark -- make it a little lighter, and add a CSS3 shadow to it or the left pane for a little spice (don't worry if it doesn't show on IE). I think the biggest problem with the current wiki is that most people don't contribute to it much. There is a wealth of info in the archives that I would really like to see digested and put on the wiki -- but that takes time that most of us don't have. In summary, I'd rather switch to a more feature rich wiki (I don't care if it's written in Perl), and have all of the people who were willing to spend time writing a new CGI-App-based wiki instead spend their time writing a more useful reference app, or write some useful pages on the new wiki! -- Mark R. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
Hi Mark On Sat, 2010-02-27 at 23:58 -0500, Mark Rajcok wrote: My 2 cents about the CGI-App wiki. I recently halted development on my app to learn about Unicode and UTF-8 (and I guess I also ended up learning about character encodings in general -- wow, did I miss some important training somewhere in my past). As usual, I found many good discussions in the CGI-App mail archive (thank you all) but nothing on the wiki. I decided I would spend a few hours and put a summary together of what I learned. I decided against putting it on the CGI-App wiki for the following reasons (i.e., lack of features): 1. no automatic table of contents generation (visit http://en.wikibooks.org/wiki/Perl_Programming/Unicode_UTF-8 and you'll see why this was important) Wow. V-e-r-y impressive. 2. no ability to edit small sections of a page Some other nice features about wikibooks - source code highlighting - discussion page (I did put a link on the CGI-App wiki to the Wikibooks doc, so if someone searches for Unicode or UTF-8, something will show up.) I don't think we should write a CGI-App-based wiki for the following reasons: I agree, for them same reasons. -- Ron Savage r...@savage.net.au http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
I believe what Mark is referring to is Stinki -- the Simple TItaNium wiKI which I mentioned to him at YAPC-NA last year. I began renovating CGI::Wiki::Simple which Lyle found on CPAN. And then I got distracted and forgot about it. So today I put it up on github, you may find it at http://github.com/jaldhar/App-Stinki It will need a few more things before it can be used as the cgi-app.org wiki. * Authentication and authorization facilities. Should be easy with C::A::P::authentication and C::A::P::authorization * better templates. * A Wiki::Toolkit::Formatter plugin for whatever wiki syntax we want to use. (May already exist.) * possibly other plugins for features in the current wiki. This is neat. Thanks for sharing it, Jaldhar. I'll take a look. Mark -- http://mark.stosberg.com/ # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
On Tue, Feb 2, 2010 at 5:20 PM, Lyle webmas...@cosmicperl.com wrote: I personally loathe Perl sites that use PHP. I used to feel guilty about what others would think if they knew I edited Perl with a non-Perl editor. I got over it. The result was better than forever talking about how someone should write an editor in Perl just to satisfy some religious belief. There are plenty of things I don't like about phpbb. But, it has features that would take years to write with a new C::A project. (Moderator controls, RSS, email notifications, private messages, etc. Plus, a *massive* community.). I'd like to write a forum in C::A that could run in mod-perl or fastcgi. Something that uses etag values stored in the database (with page content) so pages unmodified pages could be displayed with blinding speed. But, that would be a very big project (in addition to recreating what already exists). There are some other forums that aren't as heavy as phpbb. Some have liscence restrictions to prevent forking. Others lack important features. Phorum is probably the closest. But, almost all the forums with extended features are written in PHP. (Forums and wikis can be compared here: www.forummatrix.org/). There's not a lot of choice when it comes to Perl (with modern features, large user base, etc.). Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
On Thu, Feb 4, 2010 at 1:37 PM, Mark Fuller azful...@gmail.com wrote: On Tue, Feb 2, 2010 at 5:20 PM, Lyle webmas...@cosmicperl.com wrote: I personally loathe Perl sites that use PHP. I used to feel guilty about what others would think if they knew I edited Perl with a non-Perl editor. I don't think the analogy is quite right. We're talking about a Perl web application design tool. If the website for it doesn't have some kind of demo and in fact uses mostly PHP code, what good is the lib. Maybe I should go look at PHP instead. No, really, this is an important point. Look at http://jquery.com/ , http://flowplayer.org/ , http://www.phpbb.com/ , http://www.mediawiki.org/wiki/MediaWiki , http://rubyonrails.org/ , http://www.web-app.net/ , etc. I think it's important that the website selling a website tool at least demo the product it pretends to be selling. (Strictly speaking, I'm not so sure the RoR site is in RoR... how could I tell?) -- If riding in an airplane is flying, then riding in a boat is swimming. 114 jumps, 47.2 minutes of freefall, 90.4 freefall miles. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
On Thu, Feb 4, 2010 at 2:31 PM, Paul Miller listm...@voltar-confed.org wrote: If the website for it doesn't have some kind of demo and in fact uses mostly PHP code, what good is the lib. I understand your point and it has some validity. But, that's not what Lyle said, and I was addressing. He said he loathes Perl sites using PHP. That's significantly broader than a library site (for web development) using PHP. However, the dilemma is much the same. A goal to showcase C::A will be detrimental to the goals David enumerated at the beginning of this topic. There's no way you can realistically create a wiki with the features that mediaWiki has. Nor a forum with the features of phpbb (if you want to capitalize on the attributes of discussion participants to reduce wiki spam.). The fewer the features (and community), the fewer people participating as moderators, less robust anti-spam techniques, etc. I agree that it would be more consistent to have a wiki (and forum) written with C::A. But, Lyle said he'd settle for just Perl. So, we've already established a level of pragmatism. It's just a matter of how much pragmatism as someone balances the goals originally stated versus the ideals that C::A is better than anything else. Personally, I don't think it undermines C::A's credibility that there's not a widespread wiki or forum written in it. Not using the best tools just because it would admit reality (that the best tools aren't written using C::A) shouldn't be threatening. It's just reality. The question, to me, is whether to use the best tools for the job (wiki, forum, etc.). But, if C::A's community is small and that's a contributing factor to why widely used tools (wiki, forum) aren't written in C::A, then I guess it doesn't matter if a wiki (and forum) are written in C::A for demonstration purposes. However, there will be more problems with spam and participation (due to lack of features). The goals would be different than that which was first stated in this topic. Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
On Thu, Feb 4, 2010 at 4:26 PM, Lyle webmas...@cosmicperl.com wrote: Mark Fuller wrote: On Thu, Feb 4, 2010 at 2:31 PM, Paul Miller listm...@voltar-confed.org wrote: If the website for it doesn't have some kind of demo and in fact uses mostly PHP code, what good is the lib. I understand your point and it has some validity. But, that's not what Lyle said, and I was addressing. He said he loathes Perl sites using PHP. That's significantly broader than a library site (for web development) using PHP. Look at www.yabbforum.com, it's a Perl forum script, but it's site is in php. I've contacted them about this before, to be told I wasn't the first to bring it up. Based on the fact that most people wouldn't even bother to contact, I think it's probably putting a lot of people off. Yes php is currently more popular than Perl, people actively choosing Perl alternatives likely do so because they don't want to use php or asp. Having this Perl alternative run php on it's site simply wouldn't give the right message. However, the dilemma is much the same. A goal to showcase C::A will be detrimental to the goals David enumerated at the beginning of this topic. There's no way you can realistically create a wiki with the features that mediaWiki has. Nor a forum with the features of phpbb (if you want to capitalize on the attributes of discussion participants to reduce wiki spam.). The fewer the features (and community), the fewer people participating as moderators, less robust anti-spam techniques, etc. Why would the cgi-app site need to use all the features of MediaWiki? Precisely. By having a chance to create something from scratch, it can be built to be lean and spare, with all that is required and nothing that isn't. MediaWiki has a different audience, different needs. I love minimalist design, and that is why I really like pagetext.org that uses WikiCreole. CGI::App::Plugin::Wiki should really be just that... a plugin with a very minimal templating system allowing one to use as little or customize as much as needed. It's a small site and small community. We don't need lots of anti-spam features, just a good one that works. MojoMojo isn't feature rich, but serves the Catalyst site well. I agree that it would be more consistent to have a wiki (and forum) written with C::A. But, Lyle said he'd settle for just Perl. So, we've already established a level of pragmatism. I'm a Perl advocate and I don't hide it :D Personally, I don't think it undermines C::A's credibility that there's not a widespread wiki or forum written in it. Not using the best tools just because it would admit reality (that the best tools aren't written using C::A) shouldn't be threatening. It's just reality. The question, to me, is whether to use the best tools for the job (wiki, forum, etc.). MojoMojo isn't widespread, but it is a Catalyst Wiki, used on the Catalyst site. Lyle -- Puneet Kishor # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
On Thu, Feb 4, 2010 at 3:26 PM, Lyle webmas...@cosmicperl.com wrote: Look at www.yabbforum.com, it's a Perl forum script, but it's site is in php. I've contacted them about this before, to be told I wasn't the first to bring it up. I agree with you guys. But, first it was loathing a Perl site that uses PHP. Then it was a web-development library site using a forum or wiki not developed with that. Now it's a forum site using a different forum. I think that's my point too. It's a matter of degrees, not absolutes. Different levels of apparent contradiction. Balancing goals which may be contradictory (David's goal to encourage greater participation and reduce spam, while making editing easy may be diminished by a goal to treat everything as an opportunity to showcase C::A, however lightweight and featureless the result may be.). I was just saying that if David's goals are important, then a robust forum and wiki would be the way to go. Even in the most contradictory case of a forum (or wiki) site using a different forum (or wiki), I think that could be justified if the forum (or wiki) hasn't reached the desired state of development. Using something better to facilitate that development seems like a mature position. Not necessarily discrediting. (IMO.). Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
By having a chance to create something from scratch, it can
be built to be lean and spare, with all that is required and nothing
that isn't.
Speaking of that, I have some code here that implements basic bulletin board
functionality. It was only an experiment to test how DBIC::Schema works. I
will probably rework it to use DBIx::Class. It's damn slow (no caching, no
optimization of database access, no use of FastCGI etc.) and there are
working sites everywhere, but it ships with some kind of requirement
definition :)
I spent something about a week('s evenings) to implement the front end
(including the hassle applying the design to it, which I will never use
again) and 3 or 4 weeks more to implement the administrative backend.
There is a demo here:
http://alex.intergastro-service.de/cgi-bin/bulletinboard/bb.cgi
I don't think, given a proper requirement definition and some project
management, it would take much longer, if such a board would be coded by
users of CGI::Application.
Alex
-Ursprüngliche Nachricht-
Von: cgiapp-boun...@lists.erlbaum.net
[mailto:cgiapp-boun...@lists.erlbaum.net] Im Auftrag von P Kishor
Gesendet: Donnerstag, 4. Februar 2010 23:37
An: CGI Application
Betreff: Re: [cgiapp] Future of the wiki
On Thu, Feb 4, 2010 at 4:26 PM, Lyle webmas...@cosmicperl.com wrote:
Mark Fuller wrote:
On Thu, Feb 4, 2010 at 2:31 PM, Paul Miller listm...@voltar-confed.org
wrote:
If the website for it doesn't have some
kind of demo and in fact uses mostly PHP code, what good is the lib.
I understand your point and it has some validity. But, that's not what
Lyle said, and I was addressing. He said he loathes Perl sites using
PHP. That's significantly broader than a library site (for web
development) using PHP.
Look at www.yabbforum.com, it's a Perl forum script, but it's site is in
php. I've contacted them about this before, to be told I wasn't the
first to bring it up. Based on the fact that most people wouldn't even
bother to contact, I think it's probably putting a lot of people off.
Yes php is currently more popular than Perl, people actively choosing
Perl alternatives likely do so because they don't want to use php or
asp. Having this Perl alternative run php on it's site simply wouldn't
give the right message.
However, the dilemma is much the same. A goal to showcase C::A will be
detrimental to the goals David enumerated at the beginning of this
topic. There's no way you can realistically create a wiki with the
features that mediaWiki has. Nor a forum with the features of phpbb
(if you want to capitalize on the attributes of discussion
participants to reduce wiki spam.). The fewer the features (and
community), the fewer people participating as moderators, less robust
anti-spam techniques, etc.
Why would the cgi-app site need to use all the features of MediaWiki?
Precisely. By having a chance to create something from scratch, it can
be built to be lean and spare, with all that is required and nothing
that isn't. MediaWiki has a different audience, different needs. I
love minimalist design, and that is why I really like pagetext.org
that uses WikiCreole.
CGI::App::Plugin::Wiki should really be just that... a plugin with a
very minimal templating system allowing one to use as little or
customize as much as needed.
It's a small site and small community. We don't need lots of anti-spam
features, just a good one that works. MojoMojo isn't feature rich, but
serves the Catalyst site well.
I agree that it would be more consistent to have a wiki (and forum)
written with C::A. But, Lyle said he'd settle for just Perl. So, we've
already established a level of pragmatism.
I'm a Perl advocate and I don't hide it :D
Personally, I don't think it undermines C::A's credibility that
there's not a widespread wiki or forum written in it. Not using the
best tools just because it would admit reality (that the best tools
aren't written using C::A) shouldn't be threatening. It's just
reality. The question, to me, is whether to use the best tools for the
job (wiki, forum, etc.).
MojoMojo isn't widespread, but it is a Catalyst Wiki, used on the
Catalyst site.
Lyle
--
Puneet Kishor
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Eingehende eMail ist virenfrei.
Von AVG überprüft - www.avg.de
Version: 9.0.733 / Virendatenbank: 271.1.1/2667 - Ausgabedatum: 02/04/10
08:35:00
# CGI::Application community mailing list
Re: [cgiapp] Future of the wiki
Jaldhar H. Vyas wrote: I believe what Mark is referring to is Stinki -- the Simple TItaNium wiKI which I mentioned to him at YAPC-NA last year. I began renovating CGI::Wiki::Simple which Lyle found on CPAN. And then I got distracted and forgot about it. So today I put it up on github, you may find it at http://github.com/jaldhar/App-Stinki Well done for getting it started :) Wish I had time to work on it :( But sounds like David may well take this up, maybe the two of you should get talking direct (that's if you haven't already) Lyle # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
On Wed, 3 Feb 2010, Lyle wrote: Jaldhar H. Vyas wrote: I believe what Mark is referring to is Stinki -- the Simple TItaNium wiKI which I mentioned to him at YAPC-NA last year. I began renovating CGI::Wiki::Simple which Lyle found on CPAN. And then I got distracted and forgot about it. So today I put it up on github, you may find it at http://github.com/jaldhar/App-Stinki Well done for getting it started :) Wish I had time to work on it :( Thanks. I don't really have time atm either. One of the reasons I'm trying to make as many of my projects public as possible is to embarrass myself into working on them :-) But sounds like David may well take this up, maybe the two of you should get talking direct (that's if you haven't already) I like Davids idea of making this a community project. I'm sure if we all did a little bit, we could make a first class wiki in no time. -- Jaldhar H. Vyas jald...@braincells.com # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
Cees Hek wrote: On Tue, Feb 2, 2010 at 7:29 PM, Mark Fuller azful...@gmail.com wrote: Mailing lists seem so 1990. I'd ditch it and go with a forum. A forum requires me to actively participate (ie go to the forum every day to see what is there). A mailing list allows me to passively keep in touch since I check my email regularly throughout the day. I don't read every message on the list, but I at least see the subjects and look at the stuff that interests me. I think switching to a forum would loose a lot of lurkers on this list... Cees is completely right. Many of us are very busy people and wouldn't have time to monitor a forum. But having the emails pop in let us quickly scan over the subjects, while we are getting on with our work. There is no way I would have caught this thread if it was on a forum. Lyle # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
On Wed, 3 Feb 2010, Joshua Miller wrote: Saw Creole mentioned a bunch above, and while looking into it, ran into Text::WikiCreole: http://search.cpan.org/~jburnett/Text-WikiCreole/ Seems like that might be the way to go for this part. * possibly other plugins for features in the current wiki. Text::WikiCreole appears to support this already. A Wiki::Toolkit plugin? I don't think so. But it would be easy to write one. -- Jaldhar H. Vyas jald...@braincells.com # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
r...@savage.net.au wrote: Before starting such a project, everyone needs to agree to support the definitive wiki syntax: http://www.wikicreole.org/ Agreed? If you can't even agree on that, forget it. Oh, fine! (deletes his pod-in-progress for Yet Another Mo Better Wiki Syntax) [more suggestions sniped] And lastly, are /all/ existing wikis unacceptable? Yes! If so, why? Because! Um, because they're not based on CGI-App of course :-) Does it matter if we a less-than-perfect wiki, when everything in life is less-than-perfect :-)? My preference would be to use an existing one, since then our efforts can be directed to other things, rather than just reinventing the wheel. You have better things to do than that? The wheels aren't going to reinvent themselves, you know! Seriously, I'd prefer use an exiting Wiki, too, if the goal was just to get some content out there in web editable form. But we already have that. I'm thinking that the development of a cgi-app based Wiki would be an enjoyable activity for the community, and could possibly result in a Wiki that we would not only meet our content publishing and community contribution needs but that would also serve as a best-practices example of what can be built with CGI application. -dave # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
On Mon, Feb 1, 2010 at 11:01 PM, David Kaufman da...@gigawatt.com wrote: I think we definitely need to put some some anti-spam techniques to discourage the spammers, but I am worried that real users with ideas or corrections to contribute would not bother to ask for access. I want to mention again: If a forum were used instead of an email list, wiki edit access could be tied to the forum's authentication (deriving benefit from the forum's anti-spam registration techniques), and based upon a forum member's demonstrated non-spammy activity (they're a member of the wiki editor's group after 10 posts to the forum?). I believe a mailing list loses valuable attributes about participants. There's no way to correlate and capitalize upon the fact that user xyz has a demonstrated track record of not generating spam, and therefore can be trusted to edit the wiki. The other benefit of a forum (over a mailing list) is that it can exist on the same site as the wiki. The two can be linked together, helping discussion participants pay more attention to the wiki (and wiki browsers pay more attention to the discussions). One-stop location for knowledge-base and discussion information. Mailing lists seem so 1990. I'd ditch it and go with a forum. Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
Hi David, Sorry to come in late on this. As Mark said we discussed a CGI-App based wiki a while back... http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg07613.html and http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg07607.html On that second thread I found an old cgi-app wiki on CPAN. With the maintained Wiki toolkit that lives on CPAN I don't think building a new OR updating the old cgi-app wiki would be hard at all. I was supposed to implement that new design, but unfortunately the crunch hit me bad, since I've been juggling work and a Uni degree and haven't had time for much else. We could implement the new design with the Wiki update and kill two birds with one stone :) Go for it David, get this started! Lyle David Kaufman wrote: Seriously, I'd prefer use an exiting Wiki, too, if the goal was just to get some content out there in web editable form. But we already have that. I'm thinking that the development of a cgi-app based Wiki would be an enjoyable activity for the community, and could possibly result in a Wiki that we would not only meet our content publishing and community contribution needs but that would also serve as a best-practices example of what can be built with CGI application. -dave # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
Someone said: Something like Google Groups that was open source would certainly be nice. I like phpbb. It's heavy, but it's the most widely used forum software. The older I get, the more I subscribe to the ancient Chinese proverb: 10 million flies can't be wrong. Phpbb can be integrated with mediaWiki, to have the kind of shared authentication I was talking about (participants gain wiki editing status after some number of posts and some amount of time, to guard against a spammer making 10 posts in one night just to spam the wiki). As far as guarding against forum spam (which is the only risk, leading up to validated users who are trusted to edit the wiki), I like a tiered approach: 1. Captcha devices which bots have about a 20% success rate with. 2. Custom profile fields or QA which bots aren't programmed to handle. (Change these occasionally to defeat bots that might be customized to handle this particular forum.). 3. Assign new forum members to the group newly registered users until they've made 5-10 normal posts over some minimum period of time. 4. For postings by members of newly registered users, use blacklisting services like Akismet, Spam Karma II and Spam Assassin. - These tools look at the spamminess of a post, and return true/false. - If they report a post of spam, place the user in a group of reported spammers for moderator review. - If the service gave a false positive, report it to the service (to make the service better), and take the user out of the suspected group. - The result is only a few undetected spam postings for moderators to remove, and report to the service to improve its accuracy. 5. After a participant makes it through that process, they're added to the phpbb group wiki editors (which is required for them to be recognized as authenticated at the wiki, along with the site cookie indicating they're authenticated.). Personally, I'd do this on the same host as the wiki. Not Google Groups. Keep it together, and integrated so the two distinct categories of collaboration drive participants/visitors to each other. As I said before, maybe the above is overkill for the size of C::A's following. Or, maybe C::A's following would grow if it moved to something more feature-rich than a mailing list. Something where a user can see their posts, unread posts, unreplied posts, receive an email notification when a forum has been updated. See new posts via RSS/Atom feeds. It's even possible to create a forum for Wiki changes, and feed updates (diff output) to that forum as a topic for each page. Changes to the Wiki would be more visible as people participate in the other (normal) forums. And, they could watch that forum using RSS, like any other forum. (This duplicates mediaWiki's own features. But, it helps visibility when many people aren't going to visit the wiki often just to see what's happening.). Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
On 1/30/10 4:55 PM, Mark Stosberg wrote: MT5 did bring some significant changes. First, it dropped support for PostgreSQL and SQLite, so the MySQL backend is required. ( This is a downer for me, but not a deal-breaker. ) Second, the core now has support for revisions, an important feature of wikis. The core does not include a diff feature, but I suspect this could be provided by a plugin, and is something we may be able to contribute ourselves. I use MT for my personal blog. I find it attactive, pleasant to use, and fairly easy to install. I can vouch for it being light on server resources. I run it under CGI. The admin area is a little slow this way, but tolerable. The static public pages are of course fast. I also wrote a couple of plugins for it, which was reasonably easy. I put a lot of my own time into setting up the original CGI::Application wiki, as well as writing and editing a fair amount of the content. Someone else will need to play that role the second time around. Are there folks here that are intested in volunteering to help admin and maintain a new wiki / web presence ? What tools would you like to do that with? Does MT5 still use PHP or is it pure Perl now? Bob # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
Mark Stosberg wrote: Perhaps the wiki would be more interesting to use if we used a different wiki engine. Kwiki is written in Perl, but certainly never took off [...] There was some interest in building a wiki based on CGI::Application, but that hasn't materialized. I think a cgi-app based wiki would be an awesome idea. I must not have been paying attention when it was last discussed or I'd certainly have volunteered to help with that. But back to the fundamental question: If the wiki was overhauled, would you use it and maintain it more? I definitely would! -dave # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
Hi Gurunandan, Gurunandan R. Bhat wrote: I had offered Mark to port content on the wiki to Movable Type a few months earlier. At that time, Mark had very valid concerns - that MT does not offer key features required of a wiki. But that was MT4 and a re-evaluation of MT after the release of MT5 recently might be interesting. I like MT (2 or 3 years ago) but am not familiar with recent versions -- can it be used like a Wiki? I thought it was strictly blog software. I see TWiki has sprouted a blog plugin - I guess it's only a matter of time before MT grew a wiki-mode :-) -dave # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki
Hi Folks Before starting such a project, everyone needs to agree to support the definitive wiki syntax: http://www.wikicreole.org/ Agreed? If you can't even agree on that, forget it. I suggest sounding out people not on this mailing list, for ideas. There are so many people who can be pingged, e.g. http://rjbs.manxome.org/, etc, etc. Just keep track of their suggestions... And, a CPAN search for 'wiki' finds 1,967 hits. That's scary. It suggests 2 things (to me): o A lot of conversion utilities have been written between the various wiki syntaxes. o A number of projects were started and abandoned. Both these are of concern, but I prefer to ignore the first. The latter one, though, begs the question: Why? I venture that it's like millions of projects in human history - they were started based on a non-sustainable burst of energy. Bluntly, they were never going to be finished. /We don't need that!/ Either a new wiki project is not started, or it's carried thru until it's finished. Abandonment means all contributed effort is wasted. And lastly, are /all/ existing wikis unacceptable? If so, why? Does it matter if we a less-than-perfect wiki, when everything in life is less-than-perfect :-)? My preference would be to use an existing one, since then our efforts can be directed to other things, rather than just reinventing the wheel. Ron Savage # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki (was: Re: CGI::Application wiki page Examples)
Yes, MT4 is not a wiki, but do we really need a wiki for now? I find wiki's great for collaborative editting because of their very low bar for contribution. Classically, MT4's model is that of a blog, but because it offers multiple users to contribute, and offers an extensive amount of administrative control, it is really more like a CMS. Nevertheless, all that is terminology. The fact is -- it is a modern, secure, nicely designed, and constantly maintained publishing system that is created in Perl by one of the well known Perl-personalities, Ben Trott. And, MT is based on CGI::Application. Not directly, but it forked CGI::Application many years ago as a foundation, and some of the internal methods still have the same or similar names. The Open Melody project would very much like for MT to be formally based on CGI::Application again, so there would be perhaps some mutual benefit with the relationship. ( If you are interested more in the technical issues there, I wrote up notes on what could be involved in some initial refactoring: http://wiki.movabletype.org/Proposal:QueryObjectRefactor You can also search the OpenMelody wiki for references to CGI::Application: http://groups.google.com/group/openmelody/search?group=openmelodyq=application+cgi ) MT5 did bring some significant changes. First, it dropped support for PostgreSQL and SQLite, so the MySQL backend is required. ( This is a downer for me, but not a deal-breaker. ) Second, the core now has support for revisions, an important feature of wikis. The core does not include a diff feature, but I suspect this could be provided by a plugin, and is something we may be able to contribute ourselves. I use MT for my personal blog. I find it attactive, pleasant to use, and fairly easy to install. I can vouch for it being light on server resources. I run it under CGI. The admin area is a little slow this way, but tolerable. The static public pages are of course fast. I also wrote a couple of plugins for it, which was reasonably easy. I put a lot of my own time into setting up the original CGI::Application wiki, as well as writing and editing a fair amount of the content. Someone else will need to play that role the second time around. Are there folks here that are intested in volunteering to help admin and maintain a new wiki / web presence ? What tools would you like to do that with? Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Future of the wiki (was: Re: CGI::Application wiki page Examples)
The idea was that the 315 subscribers to this mailing list are the only people in the world with the slightest motivation to delete spam from the wiki and, since its not a terribly thriving, active wiki, even we members of the cgiapp community don't visit it all that much. So my hope was that by having these messages come to the list would remind people that the Wiki exists, ping them that people contribute to it, and maybe spark enough curiosity that someone checks to see what was edited, and in the process, is able to find and fix spam. In my case, this has been working, and I have been visiting more. I don't really mind the notices right now, but I can also understand that the mailing list could feel like a drag if the quality of discourse was lowered to primarily being terse automated messages about wiki updates. It seems like a nice option to be enabled per-user, but then I'm not sure I want to see all the automated updates in my personal inbox... It's my last attempt to save the Wiki. If it continues to be used more by spammers than the community, then it is not really worth the time and trouble involved in continuing to operate it. If, as I hope, these messages help spur the community to step up and contribute and help maintain and police the thing, then we'll be able to continue to have a Wiki for the foreseeable future! Since I do some website admin work myself, I also appreciate this sentiment. Perhaps the wiki would be more interesting to use if we used a different wiki engine. Kwiki is written in Perl, but certainly never took off and seems to lack some features that seem standard in wikis now. For example, it seems like a large flaw that it offers no way to enter a short message explaining *why* a change would made. Other alternatives I'm familiar with include MediaWiki (PHP...), Trac (Python...) or and gitit (Haskell...). There was some interest in building a wiki based on CGI::Application, but that hasn't materialized. I'm sad to say that there's not a Perl-based wiki that I'm aware of as becoming prosperous and popular. For me, open-source vs. closed-source is ultimately a greater concern, and I could put aside language preferences and use another open source option. But back to the fundamental question: If the wiki was overhauled, would you use it and maintain it more? Mark -- http://mark.stosberg.com/ # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Future of the wiki (was: Re: CGI::Application wiki page Examples)
On Thu, Jan 28, 2010 at 9:18 PM, Mark Stosberg m...@summersault.com wrote: The idea was that the 315 subscribers to this mailing list are the only people in the world with the slightest motivation to delete spam from the wiki and, since its not a terribly thriving, active wiki, even we members of the cgiapp community don't visit it all that much. So my hope was that by having these messages come to the list would remind people that the Wiki exists, ping them that people contribute to it, and maybe spark enough curiosity that someone checks to see what was edited, and in the process, is able to find and fix spam. In my case, this has been working, and I have been visiting more. I don't really mind the notices right now, but I can also understand that the mailing list could feel like a drag if the quality of discourse was lowered to primarily being terse automated messages about wiki updates. It seems like a nice option to be enabled per-user, but then I'm not sure I want to see all the automated updates in my personal inbox... It's my last attempt to save the Wiki. If it continues to be used more by spammers than the community, then it is not really worth the time and trouble involved in continuing to operate it. If, as I hope, these messages help spur the community to step up and contribute and help maintain and police the thing, then we'll be able to continue to have a Wiki for the foreseeable future! Since I do some website admin work myself, I also appreciate this sentiment. Perhaps the wiki would be more interesting to use if we used a different wiki engine. Kwiki is written in Perl, but certainly never took off and seems to lack some features that seem standard in wikis now. For example, it seems like a large flaw that it offers no way to enter a short message explaining *why* a change would made. Other alternatives I'm familiar with include MediaWiki (PHP...), Trac (Python...) or and gitit (Haskell...). There was some interest in building a wiki based on CGI::Application, but that hasn't materialized. I'm sad to say that there's not a Perl-based wiki that I'm aware of as becoming prosperous and popular. For me, open-source vs. closed-source is ultimately a greater concern, and I could put aside language preferences and use another open source option. But back to the fundamental question: If the wiki was overhauled, would you use it and maintain it more? Both David and you make important points, and I too empathize with David's sentiments. Allow me to say from the hip at the risk of being accused of if you complain then do something about it. I hope the community view the following in the spirit that it is offered -- constructive feedback. The cgi-app wiki is a very valuable resource, but is an outdated and old-school looking resource. Actually, such seems to be the public facing problem of most of perl-based incarnations -- perlmonks still lives in dark ages although there have been many meditations on overhauling it; heck, even the perl6 site looks goofy and not modern at all. I downloaded Rakudo Perl, and am blown away by the language. It looks be a fantastic incarnation when it arrives production ready. But that Camelia spokesbug and the amateurish, nay, un-designed rounded rectangles on the front-page with the center-piece being a button that can't make up its mind whether it wants to be rounded or square cornered, Perl6 website looks like it is for a totally un-serious tool. Compare these to stuff made with RoR, or the regular rubylang site, or the jQuery site, or sites showcasing stuff made with jQuery. They all look and feel modern. Ajaxy bits, nice logos, good color schemes. cgi-app.org is actually one of the better ones of the perl family. I just wish it were even more modern and better. It would definitely behoove if cgi-app.org were running a protected wiki written in cgi-app. I would rather the keys to the wiki were with only a few chosen ones as long as I could ask them for it in case I wanted to add or update a page or a how-to. Perhaps editing of the wiki could be allowed only by those who are members of this mailing list. That would be some measure of control that they are benevolent, or at least benign humans. Until a wiki based on cgi-app can be made by someone, there indeed are other Perl-based wiki that can serve very well -- Twiki especially comes to mind. Oddmuse is a nice looking one, and is hugely simple to implement, but may not offer the security desired. Ok. Enough of what seems like a rant (I iterate, it is not meant to be a rant). Here are some immediate suggestions -- 1. Implement a Perl-based wiki that is still being developed and has not been abandoned. This should be a stop-gap measure until a cgi-app based wiki is developed (if it is not developed, so be it... at least the cgi-app site would be running Perl). 2. Modernize the site bringing it in line with jQuery or RoR websites with modern color schemes, Ajaxy
Re: [cgiapp] Future of the wiki (was: Re: CGI::Application wiki page Examples)
top posting -- MovableType is a worthy candidate for a Perl-based CMS that also has a good security. Once again, a few folks can have the keys to operate it, and others can ask for it on an as needed basis. Perhaps, only those who have been on this mailing list for a certain period of time can be authorized. Or, some other means for double-checking the intent of the potential editors/posters. On Thu, Jan 28, 2010 at 9:47 PM, P Kishor punk.k...@gmail.com wrote: On Thu, Jan 28, 2010 at 9:18 PM, Mark Stosberg m...@summersault.com wrote: The idea was that the 315 subscribers to this mailing list are the only people in the world with the slightest motivation to delete spam from the wiki and, since its not a terribly thriving, active wiki, even we members of the cgiapp community don't visit it all that much. So my hope was that by having these messages come to the list would remind people that the Wiki exists, ping them that people contribute to it, and maybe spark enough curiosity that someone checks to see what was edited, and in the process, is able to find and fix spam. In my case, this has been working, and I have been visiting more. I don't really mind the notices right now, but I can also understand that the mailing list could feel like a drag if the quality of discourse was lowered to primarily being terse automated messages about wiki updates. It seems like a nice option to be enabled per-user, but then I'm not sure I want to see all the automated updates in my personal inbox... It's my last attempt to save the Wiki. If it continues to be used more by spammers than the community, then it is not really worth the time and trouble involved in continuing to operate it. If, as I hope, these messages help spur the community to step up and contribute and help maintain and police the thing, then we'll be able to continue to have a Wiki for the foreseeable future! Since I do some website admin work myself, I also appreciate this sentiment. Perhaps the wiki would be more interesting to use if we used a different wiki engine. Kwiki is written in Perl, but certainly never took off and seems to lack some features that seem standard in wikis now. For example, it seems like a large flaw that it offers no way to enter a short message explaining *why* a change would made. Other alternatives I'm familiar with include MediaWiki (PHP...), Trac (Python...) or and gitit (Haskell...). There was some interest in building a wiki based on CGI::Application, but that hasn't materialized. I'm sad to say that there's not a Perl-based wiki that I'm aware of as becoming prosperous and popular. For me, open-source vs. closed-source is ultimately a greater concern, and I could put aside language preferences and use another open source option. But back to the fundamental question: If the wiki was overhauled, would you use it and maintain it more? Both David and you make important points, and I too empathize with David's sentiments. Allow me to say from the hip at the risk of being accused of if you complain then do something about it. I hope the community view the following in the spirit that it is offered -- constructive feedback. The cgi-app wiki is a very valuable resource, but is an outdated and old-school looking resource. Actually, such seems to be the public facing problem of most of perl-based incarnations -- perlmonks still lives in dark ages although there have been many meditations on overhauling it; heck, even the perl6 site looks goofy and not modern at all. I downloaded Rakudo Perl, and am blown away by the language. It looks be a fantastic incarnation when it arrives production ready. But that Camelia spokesbug and the amateurish, nay, un-designed rounded rectangles on the front-page with the center-piece being a button that can't make up its mind whether it wants to be rounded or square cornered, Perl6 website looks like it is for a totally un-serious tool. Compare these to stuff made with RoR, or the regular rubylang site, or the jQuery site, or sites showcasing stuff made with jQuery. They all look and feel modern. Ajaxy bits, nice logos, good color schemes. cgi-app.org is actually one of the better ones of the perl family. I just wish it were even more modern and better. It would definitely behoove if cgi-app.org were running a protected wiki written in cgi-app. I would rather the keys to the wiki were with only a few chosen ones as long as I could ask them for it in case I wanted to add or update a page or a how-to. Perhaps editing of the wiki could be allowed only by those who are members of this mailing list. That would be some measure of control that they are benevolent, or at least benign humans. Until a wiki based on cgi-app can be made by someone, there indeed are other Perl-based wiki that can serve very well -- Twiki especially comes to mind. Oddmuse is a nice looking one, and is hugely simple to implement, but may not
Re: [cgiapp] Future of the wiki (was: Re: CGI::Application wiki page Examples)
I had offered Mark to port content on the wiki to Movable Type a few months earlier. At that time, Mark had very valid concerns - that MT does not offer key features required of a wiki. But that was MT4 and a re-evaluation of MT after the release of MT5 recently might be interesting. Regards Gurunandan On Thu, 2010-01-28 at 22:02 -0600, P Kishor wrote: top posting -- MovableType is a worthy candidate for a Perl-based CMS that also has a good security. Once again, a few folks can have the keys to operate it, and others can ask for it on an as needed basis. Perhaps, only those who have been on this mailing list for a certain period of time can be authorized. Or, some other means for double-checking the intent of the potential editors/posters. On Thu, Jan 28, 2010 at 9:47 PM, P Kishor punk.k...@gmail.com wrote: On Thu, Jan 28, 2010 at 9:18 PM, Mark Stosberg m...@summersault.com wrote: The idea was that the 315 subscribers to this mailing list are the only people in the world with the slightest motivation to delete spam from the wiki and, since its not a terribly thriving, active wiki, even we members of the cgiapp community don't visit it all that much. So my hope was that by having these messages come to the list would remind people that the Wiki exists, ping them that people contribute to it, and maybe spark enough curiosity that someone checks to see what was edited, and in the process, is able to find and fix spam. In my case, this has been working, and I have been visiting more. I don't really mind the notices right now, but I can also understand that the mailing list could feel like a drag if the quality of discourse was lowered to primarily being terse automated messages about wiki updates. It seems like a nice option to be enabled per-user, but then I'm not sure I want to see all the automated updates in my personal inbox... It's my last attempt to save the Wiki. If it continues to be used more by spammers than the community, then it is not really worth the time and trouble involved in continuing to operate it. If, as I hope, these messages help spur the community to step up and contribute and help maintain and police the thing, then we'll be able to continue to have a Wiki for the foreseeable future! Since I do some website admin work myself, I also appreciate this sentiment. Perhaps the wiki would be more interesting to use if we used a different wiki engine. Kwiki is written in Perl, but certainly never took off and seems to lack some features that seem standard in wikis now. For example, it seems like a large flaw that it offers no way to enter a short message explaining *why* a change would made. Other alternatives I'm familiar with include MediaWiki (PHP...), Trac (Python...) or and gitit (Haskell...). There was some interest in building a wiki based on CGI::Application, but that hasn't materialized. I'm sad to say that there's not a Perl-based wiki that I'm aware of as becoming prosperous and popular. For me, open-source vs. closed-source is ultimately a greater concern, and I could put aside language preferences and use another open source option. But back to the fundamental question: If the wiki was overhauled, would you use it and maintain it more? Both David and you make important points, and I too empathize with David's sentiments. Allow me to say from the hip at the risk of being accused of if you complain then do something about it. I hope the community view the following in the spirit that it is offered -- constructive feedback. The cgi-app wiki is a very valuable resource, but is an outdated and old-school looking resource. Actually, such seems to be the public facing problem of most of perl-based incarnations -- perlmonks still lives in dark ages although there have been many meditations on overhauling it; heck, even the perl6 site looks goofy and not modern at all. I downloaded Rakudo Perl, and am blown away by the language. It looks be a fantastic incarnation when it arrives production ready. But that Camelia spokesbug and the amateurish, nay, un-designed rounded rectangles on the front-page with the center-piece being a button that can't make up its mind whether it wants to be rounded or square cornered, Perl6 website looks like it is for a totally un-serious tool. Compare these to stuff made with RoR, or the regular rubylang site, or the jQuery site, or sites showcasing stuff made with jQuery. They all look and feel modern. Ajaxy bits, nice logos, good color schemes. cgi-app.org is actually one of the better ones of the perl family. I just wish it were even more modern and better. It would definitely behoove if cgi-app.org were running a protected wiki written in cgi-app. I would rather the keys to the wiki were with only a few chosen ones as long as I could ask them for it in case I wanted to add or update a
Re: [cgiapp] Future of the wiki (was: Re: CGI::Application wiki page Examples)
Yes, MT4 is not a wiki, but do we really need a wiki for now? Classically, MT4's model is that of a blog, but because it offers multiple users to contribute, and offers an extensive amount of administrative control, it is really more like a CMS. Nevertheless, all that is terminology. The fact is -- it is a modern, secure, nicely designed, and constantly maintained publishing system that is created in Perl by one of the well known Perl-personalities, Ben Trott. MT4 could allow someone, say, Mark, be the administrator (just using Mark's name as an example here), who could appoint some of the more prolific content contributors as authors, and then add more authors on a case-by-case basis. By the way, MT4 has a static publishing model -- it generates static html pages, so once the pages have been generated, there is little pressure on the server. The only live pages on a standard MT4 install are for searches. It comes with a zeroconf database by way of SQLite, and is really easy to get started with. On Thu, Jan 28, 2010 at 11:36 PM, Gurunandan R. Bhat g...@informationmatters.in wrote: I had offered Mark to port content on the wiki to Movable Type a few months earlier. At that time, Mark had very valid concerns - that MT does not offer key features required of a wiki. But that was MT4 and a re-evaluation of MT after the release of MT5 recently might be interesting. Regards Gurunandan On Thu, 2010-01-28 at 22:02 -0600, P Kishor wrote: top posting -- MovableType is a worthy candidate for a Perl-based CMS that also has a good security. Once again, a few folks can have the keys to operate it, and others can ask for it on an as needed basis. Perhaps, only those who have been on this mailing list for a certain period of time can be authorized. Or, some other means for double-checking the intent of the potential editors/posters. On Thu, Jan 28, 2010 at 9:47 PM, P Kishor punk.k...@gmail.com wrote: On Thu, Jan 28, 2010 at 9:18 PM, Mark Stosberg m...@summersault.com wrote: The idea was that the 315 subscribers to this mailing list are the only people in the world with the slightest motivation to delete spam from the wiki and, since its not a terribly thriving, active wiki, even we members of the cgiapp community don't visit it all that much. So my hope was that by having these messages come to the list would remind people that the Wiki exists, ping them that people contribute to it, and maybe spark enough curiosity that someone checks to see what was edited, and in the process, is able to find and fix spam. In my case, this has been working, and I have been visiting more. I don't really mind the notices right now, but I can also understand that the mailing list could feel like a drag if the quality of discourse was lowered to primarily being terse automated messages about wiki updates. It seems like a nice option to be enabled per-user, but then I'm not sure I want to see all the automated updates in my personal inbox... It's my last attempt to save the Wiki. If it continues to be used more by spammers than the community, then it is not really worth the time and trouble involved in continuing to operate it. If, as I hope, these messages help spur the community to step up and contribute and help maintain and police the thing, then we'll be able to continue to have a Wiki for the foreseeable future! Since I do some website admin work myself, I also appreciate this sentiment. Perhaps the wiki would be more interesting to use if we used a different wiki engine. Kwiki is written in Perl, but certainly never took off and seems to lack some features that seem standard in wikis now. For example, it seems like a large flaw that it offers no way to enter a short message explaining *why* a change would made. Other alternatives I'm familiar with include MediaWiki (PHP...), Trac (Python...) or and gitit (Haskell...). There was some interest in building a wiki based on CGI::Application, but that hasn't materialized. I'm sad to say that there's not a Perl-based wiki that I'm aware of as becoming prosperous and popular. For me, open-source vs. closed-source is ultimately a greater concern, and I could put aside language preferences and use another open source option. But back to the fundamental question: If the wiki was overhauled, would you use it and maintain it more? Both David and you make important points, and I too empathize with David's sentiments. Allow me to say from the hip at the risk of being accused of if you complain then do something about it. I hope the community view the following in the spirit that it is offered -- constructive feedback. The cgi-app wiki is a very valuable resource, but is an outdated and old-school looking resource. Actually, such seems to be the public facing problem of most of perl-based incarnations -- perlmonks still lives in dark ages although there
