Improving CPAN using Google sidewiki

[EvanCarroll]

As the wiki-guy, I'm wanting to, again, address the flaws in cpan.org, and also perldoc. This is a centralized hack to solve a problem that will probably be existent until at least perl-6-cpan. I propose we kill off ANNO Cpan in favor of google side-wiki for doc editing.

Firstly, sidewiki is new so let me describe it. It permits you to note the page, or a statement with a very simply rudimentary comment -- much like the old anno-cpan but better. Google stores these and then when you browse the page you can optionally view the sidewikis on the page. All of this is implemented through a Firefox and Explorer extension. Why is cpan a great application of sidewiki?

Simple, cpan.org module urls are specific to a module version -- which are never really updated without upping the new version number. And sidewiki, will allow people to do this on the real cpan.org, without having to use an alternative site for docs. It will also eliminate the need for-specific registration, as /most/ of us /probably/ have google accounts. When a new version of the module is released there will be a new page for us to wikifiy. The author can use the current page w/ the side-wikis as notes for improvement, and the page without the sidewiki's will remain more authoritative -- which is what bugs most people about decentralized wikis.

What led me down to rethink this problem with the new google-provided toolset was File::ShareDir 1.0 which has a minor two year old doc-bug that just got me last week. I believe my fix for it, found here with the sidewiki extension: File::ShareDir was an elegant way to publish a solution, and even link it to the old the doc bug in rt.

Ideas?

UPDATE as an update, there is an official API into sidewiki as well sidewiki api, if anyone wants to create something that can submit the doc changes as rt tickets muahah.

[Tanktalus]

Um, maybe try posting this again in the future ... when sidewiki supports more than just Windows/ia32. Those of us running anything else don't get to take advantage of your wiki contributes, but we can take advantage of, and contribute to, the annotations that annocpan provide.

Update: My initial problem was trying to install from the google.com/sidewiki site. That didn't work so hot. After some googling, I found the beta toolbar that works. Of course, that brings up a new way to reach the same conclusion: it's beta. And this is the toolbar here - something not normally in beta. At least wait until the toolbar is stabilised before trying to get the Perl community to commit to it. Try it out, sure, but commit to it? Not so much.

[EvanCarroll]

I know it works for 32bit Firefox/Linux. And, I'm tempted to say it works for 64bit Firefox/Linux too. Other than that, you're talking about a /very/ small percentage of perl *developers* -- not end users of the modules: I make my stuff on 32-bit Linux, and people often install on BSD/AIX boxes. ANNO Cpan is old, its adoption rate is evidence that it is not a good solution.

UPDATE: see above notes for api links :

[moritz]

Do you have any data to support your statement that it's a very small percentage we're talking about?

Since most Perl developers I know work on some unixish systems, I'm not inclined to simply believe that.

[merlyn]

Other than that, you're talking about a /very/ small percentage of perl *developers*

You're apparently ignorant of the ever-increasing use of Mac OSX by the Perl community. And no, this doesn't work with Safari either, my preferred browser.

When there's a cross-browser solution, propose it. Until then, dead in the water, please.

[chromatic]

Relying on a for-profit company to act in Perl's best interests is a bad idea. No piece of CPAN or Perl ecosystem infrastructure should depend on the whims of such an organization. (Evidence: is Perl.com more or less useful than it was this time last year?)

[Corion]

It is just as useful :)

On the other hand, as long as you can get your data out of the service again, you're not worse off with a premade solution when the premade solution goes away.

[herveus]

Howdy!

Google Toolbar (and sidewiki) are too tied to specific browser environments to be useful as a replacement for anno-cpan at this time. It's not clear if this will work in my home environment at all (Mac), and it certainly doesn't support all of the browsers I use here at work.

It's an interesting idea that isn't quite ready for prime time.

[Anonymous Monk]

I think it will never be, too much vendor lock-in

[JavaFan]

Sidewiki, PageRank, and future page-related services are part of the enhanced Toolbar. For enhanced Toolbar features to work, Toolbar has to tell us what site you're visiting by sending Google the URL

Giving Google a complete history of what I'm browsing? I don't think so. I value my privacy (or what's left of it on the web) more than annotation from random people.

[Anonymous Monk]

It is worse than "safebrowsing" features (basically report every website visited, but pretend its somehow private/encrypted/hidden)

[tirwhan]

I am a CPAN author (<full disclosure>with only 2 active modules certainly not a major contributor, but every little bit counts</fd>) and I do not have nor will ever have a Google account (that's not because I think Google is EEVIL but because I am careful about what information they get from me). Also, I work on a 64bit-Linux system, which by your own statement would prevent me from using this tool.

Aside from the fact that this system would exclude me, I find the all-including nature of Perl and CPAN one of their most appealing features. So I would strongly disagree with adding any tool into the general CPAN infrastructure that does not support a wide range of diverse clients. If you find anno-cpan lacking, maybe time would be better spent improving it?

[Lady_Aleena]

Evan...it is a good idea, but are you going to include other browsers into this eventually? There are Google Chrome, Safari, Opera, Konqueror, etc. etc. etc.

[Zen]

I am disturbed by the google and apple fans that conveniently forget what it was like being beneath microsoft's iron fist. They're both big business, not in perl's best interest, and putting an i or G in front of it doesn't change that. I'd like to see some open source, cross-platform solution here.