Nonetheless, it'd be cool.

Dear artist,

There's something I've learned while pursuing several projects: releasing them is a blessing (Yay, it's done!) and a curse (Uh-oh, people are using it, and they want features/fixes). There's never a point where you can stop sinking time into a project, unless you abandon the code or find people to adopt it.

That said, I am the main author of a somewhat well-known library of Perl modules that has inspired a lot of ideas, "finished" and otherwise.

Things I've managed to release:

A collaborative crossword/chat server that allows people to work on AcrossLite puzzles together. A group of people in Ireland have used it to win prizes from newspaper puzzles.

A multi-host ping monitor which lets you see the status of several routes at a glance. I use it to keep tabs on my Internet provider, which you can see from the screen shots.

A combination bot and web server that lets people share Perl code without pasting it to IRC channels. Perl channels on at least three networks are currently using it.

Another hybrid IRC bot/web server that gathers URLs from conversations and enters them in an integrated web log.

Things I'd like to release someday, if I ever get the time:

A Zope-like content management server, or at least a wiki.

A MUD/MOO system that uses a secure subset of Perl for scripting. I've been able to write extensive documentation on this, but it's a very large project and hasn't gotten off the ground.

A combined SMTP and POP3 server. I have most of the POP3 server done, but I haven't had time to write the SMTP services. I think a web interface for configuration and management would also be nice.

A Curses based XFrisk client. I promised sheriff_p I would get the networking side of it done and haven't had time to integrate the networking code with the Curses based map.

A high-level language for defining state machines, with filters that generate Perl modules and GraphViz diagrams of the logic flow.

The Distributed Monkey Project, which would be an implementation of RFC 2795. Sometimes projects just happen for the fun of it. :)

An infobot with hotsync between IRC and a PDA.

Umm... those are the ones I can remember right now.

-- Rocco Caputo / poe.perl.org

rcaputo writes:

A Zope-like content management server, or at least a wiki.

I hear you. A starting point would be to make a perl equivalent or mini-equivalent of ZODB, the object persistence engine, which is really just one big file and an index file. Make a server that takes an object, serializes it with Data::Dumper or something else and appends it to the big file, and makes a note in an index file of the byte offset for that object id.

Then add some higher level functions on that as rollback (find older version of object id in file and copy that to end) and compact (write new file with latest unique object ids, chosing the one last in file, overwrite old file with new file).

Sounds very doable...?

/jeorgen

jeorgen writes:

A starting point would be to make a perl equivalent or mini-equivalent of ZODB, the object persistence engine, which is really just one big file and an index file.

The CPAN has several distributions that handle persistent objects. I'm not familiar with ZODB, so I can't say which would be most appropriate.

On the home-grown side of things, I have a DB_File wrapper that uses DB_BTREE to provide multiple keys for a DB_RECNO list of records. It's old, pre-Storable code, though, so I haven't been eager to show it off. It's also incomplete: It doesn't support dropping keys or tables, it doesn't handle adding keys to a table with existing records, and it doesn't have undelete or pack.

Speaking of pack, I also have part of a paged b-tree database driver that makes extensive use of pack() and unpack(). It was inspired by the note at the end of the pack() description in the first edition Programming Perl:

Note that, although all of our examples use literal strings as templates, there is no reason you couldn't pull in your templates from a disk file. You could, in fact, build an entire relational database system around this function.

They're right, but it's not as easy as that casual remark would make it seem. As key pages fill up, they must be split into smaller ones. That was just too much for me, and that's where the project sits today.

These remind me of yet another project idea: A web catalog of all the little bits of code I've accumulated over time. I have a lot of half-baked ideas (see above), test cases, benchmark programs, and code doodles. Currently they're rotting in a directory without an index or any way for the rest of the world to see.

If there's any one idea that could save the world, that last one would be it. I think there are a lot of good ideas rotting on coders' drives. A system to publish them would connect that stuff with the people who have the inspiration and time to develop it.

-- Rocco Caputo - troc@pobox.com - poe.perl.org

I have a lot of fun coding Perl to just about any application that allows for a Perl interface. My IRC client (XChat) and my AIM client (Gaim) both allow for extensions in Perl, which is an absolute riot, and allows for some event-driven programming, which is something I don't get much opportunity to do in Perl outside of Tk.

Extending applications in Perl seems small until you start to think about what outside applications, etc., you can tie into. Databases, web servers, whatever. I don't know if any of this is earth-moving work, but it's a hell of a lot of fun.

Something like that would be very interesting.

/jeorgen
-not affiliated with theBrain :-)