Props for actually making it. I remember your original email to the
list, it was brutal :P

I would suggest implementing renewals. This is a favorite for most
patrons. But also imagine the scenario where a book is due to the
original lender but doesn't mind letting you keep it longer. Currently,
you must recatalog the item. With renewals, you could just renew the
book instead. This feature would kill 2 birds with 1 stone.

Brice Stacey
Digital Library Services
University of Massachusetts Boston

-----Original Message-----
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Elliot Hallmark
Sent: Saturday, April 23, 2011 5:27 PM
Subject: [CODE4LIB] distributed library alpha server up, feedback


It was at the end of last year that I came here saying I was writing an
source ILS for a distributed (book sharing) library.  While I had lots
enthusiasm and time for it at the time, our development computer didn't
the capacity to run a solr based discovery front end.  Even though the
end was ready for feedback (though still very alpha), I dallied in
the IP because there was no discovery layer.

In the interest of moving forward, and since a complex discovery layer
not be necessary for a while (not for < 100 books), here is the IP.
check it out and give feed back.  Play around with whatever, this data

If this IP changes, I'll let y'all know on this thread.

Soon I would like to use this system at our private alternative
school<>in hopes that it would
facilitate folks letting us use their excellent
books, since they would be lending them, not donating them.  Having a
database keeping track of who owns the books would give a little peace
mind.  in the future, setting up a network of libraries would be easy.


1. This is a distributed library, where a book enters the system through
primal loan (from owner to library), and is due back at some point.  The
book or item can be further lent to a regular borrower, or to another
library (which inherits lending privilages).  extending lending
must be done through the administrative back end, so it wouldn't happen

2. The "discovery layer" is severely crippled because I don't want to
a indexer for our MARC records unless it becomes necessary (ie, better
searching is needed but writing a VuFind driver or integrating with
isn't yet feasible).  All books entered in this system also have MARC
records associated with them, so a solr or other front end can be added

3. If you'd like to try uploading a MARC record, email it to me and I'll
it up for anyone to enter through the cataloging app.

4. This is written in django.  Hooray for python!

5. This is not at all perfect yet.  here is my todolist so far (please
to it):

when checking a book out, do not allow a due date later than the current
lease on the book.
subtitle, does this really need to be limited to 100 characters?
create an end of day script that:
   sends emails to books that are due back soon
   sends emails to books that are overdue
activate fines model and add an Fine.calcuate() method
make a legit zipcode field. current one accepts <5 digits

thanks for reading,

Reply via email to