Why limit the project, though? It shouldn't be that difficult to create an application that organizes and indexes ANYTHING, from books and CDs to flowers to pigs. In fact, if we simply create a databasing engine and a front end, we could create a standard module for any type of index.

For example, you take the base application and write a module for it that defines what the objects are, what the index key is, and other useful bits. It could be from something as simple as a text file to as complex as a program extension with added functionality. So we could create (to follow your example) a CD Library module that simply defines the key fields (Title, Artist, Track listings, Year, Label, Personal rating 1 - 10) or we could create a module that defines all that AND includes the functionality to populate the fields from CDDB. Someone else might code a module to define MP3s - and the extended functionality is to create playlists for XMMS or WinAmp. A book module with the extended functionality of searching $bookseller_of_choice for other works by the same author, or (later on) eBook versions of the title.

Who needs a CD or book manager when you can have both?

For site hosting, I'm sure server space could be found; I don't think Perl Monks should actually host it. I'd be in favor of posting the code to Perl Monks at every stage, though, and regular updates on how the project is working and organized in the much-debated Projects section.

- Ozymandias

I don't see hosting as being an real issue. With the event of DSL, Cable, et al, I am sure that many project members would be willing to setup a staging area and a production area at home. I would gladly do it on my own machines, but if you try tracerouting any site in Brazil, you'll see that the backbone just makes in inviable. :o/ The offer still stands though. I can spare some space on my P200 (currently running SuSE Linux 6.4 and serving as a firewall / gateway).

What would we need? A dedicated box or just the usual Apache/FTP/SSH/MySQL combo?

What I find hard is pointing out (a) project manager(s). The manager job alone would probably be harder than the coding work.

#!/home/bbq/bin/perl
# Trust no1!

That's the point of the project. There are, I think, several project managers who hang out here; I am one, I just don't manage development projects much. The idea is to teach developers how project management works, and what it's like to be a part of a "professional" project. Not just a CD and book organizer, although I do kind of like the idea for a number of reasons.

What I like about this is the possibility for really getting some of the people here involved. We have our fair share of Saints and Gurus; vroom, merlyn, quite a few others who do this for a living or are stars in the Perl community. We also have quite a few who only code for fun, and we have still more who really WANT to work as a developer, but they've never been able to really get started. IRL I like to hire entry-level people for jobs and then actually bring them along to better positions; I've even hired high-school kids as low-end technicians and helpdesk support. This is a chance to do the same in the Perl community.

- Ozymandias

As far as organization goes, we could probably go with something as simple as a restrictive CVS setup. Everyone would have an assigned section, and could only do a write lock for code from that section.

My school has about 5 linux boxes that arent going to be in use at all this summer. It might take a little work, but we could get permission to use one as a dedicated box.

-Jules Kongslie

xeh007@yahoo.com

• Build a section off of Perl Monks
• err, I failed to find any free ones that would be suitable. I know there are some...

I write Perl scripts for fun (and, as a sys admin, the occasional work reduction) but have been hindered by the fact that I've not had any real training in programming as well as a general lack of insight on how to approach problems programmatically so I feel that many of my grandiose ideas are well beyond my abilities. This project would help immensely by providing a step-by-step inside view of programming practices as well as project/progamming management.

This would be just the thing to help those of us out here who don't have the skills (yet) but do have a strong desire to create, an interest in progamming, and a love of Perl.

I too would love the opportunity to contribute to, as well as learn from, this project idea.

Incorrect. We're specifically organizing this so that people work on things they DON'T know, while helping others with the things they DO know.

With the possible exception of the program management; I've done project management before, and so's jcwren, we've just not done it this way before. It'll be fun, come play.

- Ozymandias

"The first thing that probably should be done is to establish everyones CVs/abilties and where they stand on the project hierarcy..."

And then turn it on its head. Make the managers coders and the coders managers.

... I don't want to belong to any club that will accept me as a member, as Groucho said.

Seriously though, the way to learn is to break something and then get it working again. I agree entirely with the need to establish the requirements spec first.

muppetBoy if you sign up then it probably doubles the UK contingent - which can't be a bad thing. Pete

Oh, I should add that I am definitely an advanced newbie (yet newbie nonetheless) when it comes to Perl.

Glad your in for the project.

These are some of the issues we need to decide, first. Are we even going to use a database? As in, do we want a finished project that requires mySQL or postGres to be installed, or would we prefer CSV (Comma Separated Values) files? If we want a cross platform product (and that's what this is, if we were a real company), we need to know what users are willing to install to run the product.

mySQL is free for Linux, but as I seem to recall, requires a license fee for NT (this may have changed. I can't get to the tcx.se site at the moment).

But in any case, you're definitely correct. If we don't do the design correctly from the start, it could rapidly come back to haunt us.

--Chris (look Ma! No speeling errors this time)

A database will almost certainly be overkill for a project of this scale. The overhead of a database is just not worth it when the dataset is as small this figures to be; see jwz's rant about mail summary files. I also think a database would add too much complexity to a tutoring project. My ought-two cents, anyway.

Well, my thought is that we use the DBI module and have a global variable $DATABASE that stores the type of database the user has. That way, they just input the name of the database and if DBI supports it, we're ready to roll. The problem then becomes ensuring that we only implement functions that all dabases can use, or develop separate routines for each database. This can be a hassle.

If the user only has CSV available, we'll have performance issues to deal with if the database grows significantly. We also wouldn't also wouldn't support transactions as many dabases (CSV and MySQL, for example) do not support them. Of course, for a small-scale indexing application, these may not be significant concerns.

Hmm... I could go on for hours. This will have to be dealt with in whatever means we come up with for communication on this project.