The MetaCPAN Front End
Olaf Alders
1) search.metacpan.org is excellent and it will remain, but we need something that is SEO-friendly and is built in a web framework most Perl devs can contribute to. One of the main things that's (probably) holding us back from getting commits is the fact that a lot of people aren't as heavy into JS development as @ioncache is. If we put something together in a more traditional format, we'll get more pull requests. We'll also not be forced to work around JS limitations
2) moonk is proposing a front end as part of his GSOC proposal. If his proposal is accepted and there is already some kind of front end in place, his job will have been made much easier. He can then focus on cool functionality rather than having to lay the groundwork first
3) We'll have a way of getting *cpanvote* into use without forcing a GreaseMonkey script installation
4) We can start getting traffic in from Google searches, which will, in turn, drive the use of cpanvote
I think this is the biggest and best practical use of the API at this point. Here's what I see happening:
* Uses a light-weight framework (I think Dancer would be perfect)
* TT (or something which implements the full TT spec)
* Uses sawyer's MetaCPAN::API where it makes sense
* Borrows the heavy jQuery goodness of search.metacpan but also degrades gracefully for Google etc
* resides at www.metacpan.org
* begins by re-implementing the functionality of search.metacpan and then builds new functionality from that point
As part of this project, I will tag the API in its present form at some very low version number. We will then pull all of moonk's work into the master. search.metacpan and api.metacpan will continue to work off the *old* master. We'll use the new front end as a test bed for moonk's work.
It sounds like a lot of work, but really a lot of it can be done in a couple of weeks. Getting a basic search going is trivial and a lot of the JS has already been taken care of in search.metacpan
As usual, I'm looking for feedback and will regard silence as implicit approval. ;)
Olaf
David E. Wheeler
> 1) search.metacpan.org is excellent and it will remain, but we need something that is SEO-friendly and is built in a web framework most Perl devs can contribute to. One of the main things that's (probably) holding us back from getting commits is the fact that a lot of people aren't as heavy into JS development as @ioncache is. If we put something together in a more traditional format, we'll get more pull requests. We'll also not be forced to work around JS limitations
>
> 2) moonk is proposing a front end as part of his GSOC proposal. If his proposal is accepted and there is already some kind of front end in place, his job will have been made much easier. He can then focus on cool functionality rather than having to lay the groundwork first
FWIW, I'm nearing initial release of the PGXN search site. I'm quite pleased with it, in that it relies entirely on the API for content. It's a thin wrapper, really. If you're interested, you can get it here:
https://github.com/pgxn/pgxn-site
Just install the pre-reqs (all on CPAN except WWW::PGXN, which is at https://github.com/pgxn/www-pgxn) and then fire it up with
plackup bin/pgxn_site.psgi api_url http://api.pgxn.org/ errors_to to errors_from from feedback_to to
Then you can see the actual site at http://localhost:5000/. It'll go live at http://pgxn.org/ later this week I hope.
Anyway, I pitch this just to kind of show what's do-able with frankly very little code (almost all templating) and a good API client library.
> 3) We'll have a way of getting *cpanvote* into use without forcing a GreaseMonkey script installation
>
> 4) We can start getting traffic in from Google searches, which will, in turn, drive the use of cpanvote
This is why I didn't do a JS app, at least to start: I want extensions on PGXN to get good Google Foo.
> I think this is the biggest and best practical use of the API at this point. Here's what I see happening:
>
> * Uses a light-weight framework (I think Dancer would be perfect)
Dancer is nice. I personally just use Plack with Router::Resource. Very clean.
> * TT (or something which implements the full TT spec)
> * Uses sawyer's MetaCPAN::API where it makes sense
One of the things I did with WWW::PGXN was to allow it to take a file: URL for the API URL. Then it reads directly from the file system. No network overhead. This is how the production server will run.
> * Borrows the heavy jQuery goodness of search.metacpan but also degrades gracefully for Google etc
> * resides at www.metacpan.org
Might be nice, though might be overkill for MetaCPAN. The PGXN search site has no JS at all. It comes across as purely static content. This is a good thing.
> It sounds like a lot of work, but really a lot of it can be done in a couple of weeks. Getting a basic search going is trivial and a lot of the JS has already been taken care of in search.metacpan
If you have a solid API and a site design, it won't be a lot of work. The PGXN site took me a while, but that was in part because, as I developed it, I would realize that I needed to make changes to the API. SO I kept going back and forth. The result is very promising, though.
> As usual, I'm looking for feedback and will regard silence as implicit approval. ;)
I'm peanut gallery here, but it sounds like a good move. :-)
Best,
David
Yanick Champoux
On 04/02/11 11:33, Olaf Alders wrote:
I think it's time to have a conversation about building the MetaCPAN front end. And, by conversation, I basically mean just getting it done and figuring a lot of it out as we go along. Here's what I'm thinking: 1) search.metacpan.org is excellent and it will remain, but we need something that is SEO-friendly and is built in a web framework most Perl devs can contribute to. One of the main things that's (probably) holding us back from getting commits is the fact that a lot of people aren't as heavy into JS development as @ioncache is. If we put something together in a more traditional format, we'll get more pull requests. We'll also not be forced to work around JS limitations
2) moonk is proposing a front end as part of his GSOC proposal. If his proposal is accepted and there is already some kind of front end in place, his job will have been made much easier. He can then focus on cool functionality rather than having to lay the groundwork first
3) We'll have a way of getting *cpanvote* into use without forcing a GreaseMonkey script installation
* Uses a light-weight framework (I think Dancer would be perfect)
* TT (or something which implements the full TT spec)
* Uses sawyer's MetaCPAN::API where it makes sense
As usual, I'm looking for feedback and will regard silence as implicit approval. ;)
Btw, anyone on the list going to be at YAPC::NA this year? Unless things changes, I should make it there. First YAPC ever. Me's excited. :-)
Joy,
`/anick
Olaf Alders
On 2011-04-07, at 10:38 AM, Yanick Champoux wrote:
>
> Well, here's some explicit approval. All this sounds excellent.
Thank you!
>
> Btw, anyone on the list going to be at YAPC::NA this year? Unless things changes, I should make it there. First YAPC ever. Me's excited. :-)
This might the first YAPC in a while which I'll miss, but I'm hoping I can somehow manage to go. I would think @ioncache will be there, even though I'm usually his ride. ;) ddoyle, are you planning on going?
A MetaCPAN BOF would be called for.
Best,
Olaf