On Tue, Nov 20, 2001 at 11:08:40AM -0600, phil at rephil.org wrote: > I'm thinking about how to handle these things without letting them > become burdensome. Not that LUG members couldn't do it all on the > honor system, but someone's going to borrow a Perl book and get lost > in their coding and forget that they forgot to return it. I don't > have the answer yet, but if I think of something, I'll let you know. I think James was hinting to creating a database and web interface to the TCLUG Media Exchange. Might I suggest PHP and PostgreSQL? ;-) (BTW, what's the best way to use php on the command line? I'd love to do a getopts style of application so that I don't have to rewrite my PHP scripts into another language. Otherwise, I'm dumping PHP entirely and going for mod_{python,ruby} and {Python|ruby}.) Hell, I'd even do C, just because. Anyway, procmail is definitely the shit when it comes to handling email. I used the procmail-lib/commands.rc as a template to create a bunch of email accessible command/replies. (send email to me titled "get info" to see what I mean). Anyway, as with any database or application, you can write a cron script that generates an email report to send off to the lender or the borrower. Also, this discussion of a Media Exchange intrigues me. I'm referring to it as a media exchange instead of a library for of a copule reasons: * Centralized libraries require space, staff, and management. * These requirements cost money and time. We don't necessarily want to limit ourselves to writing an application to only manage a centralized library. Instead, we could write an application to centralize the exchange of media between two parties. One party could certainly be the TCLUG Library, but why not provide a way for me, as a user, to catalog my books for use with the exchange. The application could keep track of the lenders, the borrowers, and media, and the exchanges thereof. Tables you might need for a normalized DB: Data Tables Relational Tables ------------------------- ------------------------------ contact (users) contact_address (relational) address (addresses) address_phone (relational) phone (phone numbers) contact_phone (relational) uri (URI's) contact_uri (relational) media (book, tape, etc.) contact_media (relational) media_exchange (relational) Lookup Tables ---------------------------------------------------------- contact_status (missing,active,inactive,unknown) address_category (home, work, etc) media_category (cd, tape, dvd, book, magazine, game) media_status (missing,checked out,reserved,available) exchange_status (pending,approved,declined,inroute,active) exchange_type (checkout,return,possession) If you use PostgreSQL, you can set up triggers to update many of the lookup fields for records as well as trigger email updates and reports. Joe Smith reserves the Camel Book from Jane Doe for Dec 12, 2000. INSERT INTO media_exchange (media_id, exchange_type, date, contactid_from, contactid_to, reason) VALUES (1002, 0, '2001-12-12', 234, 237); Joe Smith receives an email from the exchange on behalf of Jane with two URI's, one for approve, and one for decline. ETc etc etc...I have to get back to work now... -- Chad Walstrom <chewie at wookimus.net> | a.k.a. ^chewie http://www.wookimus.net/ | s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD