On Sat, May 30, 2009 at 7:56 AM, Mark Overmeer <m...@overmeer.net> wrote: > * Andrew Whitworth (wknight8...@gmail.com) [090530 00:24]: >> I agree. Doing one thing well is so much better for everybody then >> doing a million things poorly. An assorted "blob of data" repository >> is far less valuable to the Perl5, Perl6, and Parrot communities then >> a dedicated library repository is. > > Why? Ever heart of extensible meta-data. Can be done in two ways. > The idea is tha, on the three levels of implementation (see recent > email in other thread), you have some meta-data.
I'm not saying we *can't* create a general repository for all sorts of nonsense, I'm saying that we *shouldn't*. It doesn't matter what kind of meta data you use, or how you structure your URI, or whatever: It's a bad idea. In this case, we should follow the maxim that "less is more", and realize that a tighter focus will create better value. People are going to form a one-to-one association with your project and what they expect to find there. When I think "email", I immediately associate that in my mind with "gmail". When I think "encyclopedia", I make an immediate association to "wikipedia", and vice versa. What do we want people to think about when they think about CPAN, "dynamic software packages" or "all sorts of assorted garbage with extensible metadata". > The ONLY difference between a "specialized" implementation of an archive > and a flexible one like I propose, is that in the latter you are forced to > clearly assign meta-data facts to one of these three levels. But there is > no limitiation in the amount and content of the meta-data you can collect. If you want to create an infrastructure that is vastly extensible and too clever by half, that's you're prerogative. I don't care what software infrastructure we use for a new CPAN, nor what methodology is used to design it. What I do care about is that the final CPAN website that we end up with only contains packages related to Perl5, Perl6, and Parrot. Create a server that can theoretically handle images and other garbage if you want to, but we should make sure the site administrators disable that feature immediately. > Well, so your worries are unjustified. And the two simple solutions as > I promissed in the first line of my comment: > 1 Add three seperate meta-data fragments to one blob > 2 Create one meta-data file which contains all three components. > As simple as that. Again, we are capable of doing this from a technical standpoint. It's still a bad idea. --Andrew Whitworth
