On May 23, 2011, at 11:52 AM, Jeffrey Thalhammer wrote: > Historically, CPAN mirrors have always been static files. In other words, > the paths in the 02packages file always pointed directly to some physical > file on disk. This made it possible to access mirrors the with the older > ftp:// and file:// protocols supported by CPAN.pm. It also made > synchronizing the mirrors easy with tools like rsync.
Yep. PGXN is the same, although I've built an API server that has a dynamic interface for searching. > This has worked well for a long time. But the need to support older > protocols limits the flexibility of a CPAN mirror. If you drop support for > ftp:// and file://, and just focus on http:// then things can become more > interesting. This open the door for a CPAN server (like the PGXN::Manager) > that can do all sorts of things. For example, it could serve up distros that > are spread across multiple remote machines. Or they could be stored in > version control system or database. Or you could present a view of the > mirror that meets certain criteria, such as by time, or cpantesters results, > or by author, or by kwalitee scores, or by some other metadata (like > http://cp2011-05an.barnyard.co.uk/). The concept of a CPAN server also > provides a convenient hook for plugging in other services, like a private > PAUSE or MetaCPAN. > > I'm not saying that *the* CPAN should work this way. I'm just suggesting > that a *private* CPAN could work this way. What I've tried to do with PGXN is to get the best of both worlds. At the lowest level, the mirror generated by PGXN::Manager should be very simple, with all static files. But many of those static files are JSON files, and so every mirror is a lightweight REST API server without any additional work required. Then anyone can build a service using the API. Or they can build new mirrors that do additional stuff with the data, which is what the API server does (adds additional info to some JSON files, generates HTML pages, manages full-text index, etc.). So take the static stuff, and build something dynamic on top of it, either using its API or by adding to it. Best, David
