On Thu, Apr 02, 2009 at 12:35:08PM +0200, LAURENT Henri-Damien wrote:
Dobrica Pavlinusic a ?crit :
Back in October, I worked a bit on RFID reader protocol as described in
http://lists.koha.org/pipermail/koha-devel/2008-October/008395.html
Now, I have something to show:
http://blog.rot13.org/2009/04/comet_experiment_rfid_reader_with_koha_data_in...
In the end, it will probably be Koha add-on to support user cards and items checkout/checkin, but I'm wondering if this is interest in occasional e-mail from me about status of this on koha-devel since I didn't really got any response last time.
Hi You have done some good job. Really.
Thanks :-) I just don't want to spam people with something they are not interested. Having said that, let me mix-in my RFID horror story about our implementation: if you DO intend to implement RFID as a contact-free barcode (that's really a right way to think about it), there are two important things that we discovered so far: 1. you are suggested to implement different readers for patrons and for books. We didn't do that (and used ISO for all chips) so now we can "secure" our partron cards by mistake (because 3M software is on checkout mode and somebody walks by) so door rigs on them. This is primary reason that I'm trying to replace RFID stack anyway. 2. it really important to also record RFID SID (tag serial numbers) -- sometimes reffered as hexadecimal numbers, sic!, because other systems you might want to integrate with your data might need SIDs because they *can't* read information that you recorded on card.
Having no answers on this list when doing a work for a special feature is not so unusual. We all have our problems to solve and timelines. And sometimes what you are doing is vital for you but not so critical for others. Still I think your work is interesting. But problem of integration with Koha trunk is an other question.
My second problem (SID numbers) require schema modifications to Koha. We allready have local shema: -- improve security of borrowers data adding last_updated timestamp alter table borrowers add last_updated timestamp ; update borrowers set last_updated = dateenrolled ; -- useful tracking information about RFID cards alter table borrowers add column card_issue_date datetime; -- store tfid card SID (serial number, read by dumb readers -- and needed by virtual-ldap/lib/LDAP/Koha.pm alter table borrowers add column rfid_sid varchar(16); create unique index borrowers_rfid_sid_idx on borrowers(rfid_sid); so I don't really expect easy merge with upstream.
How to best do it and not happen to come to have many SIP implementations or one RFID reader for each RFID vendor ? Maybe SIP and some xml APIs can make it. Jean-Andre Santoni worked on ILS-DI draft implementation.
SIP is somewhat limited for my use. I would really like to be able to report more that that SIP can push and support programming of chips. In fact, I don't have clear idea how to push write requests back to reader. I will probably modify meteor server to responed with pending requests (e.g. chip writes) instead of returning O.K., so that Koha can connect with simple socket connection to comet server and request chip write. Since I'm deploying RFID reader script on Windows, I would really like to keep dependencies at minimal, and move all inteligence to server side, which has additional advantage of easy logging and auditing (for debugging if nothing else :-)
Maybe send your patches to patches@koha.org and wait for comments could also be a way to do.
Thanks for hint. I was wondering what is the right way to contribute upstream :-) I will first cleanup our LDAP changes (bind as user and utf-8 encoding when replicating entry for first time) and submit them.
I really would like to have your work rather into a contrib tree or something which would be optional and easily selectable and setup. Do we need one ?
I only modification to Koha would be additional page with subset of item data needed for display. Think of it as small embeddable item display which might be useful for other AJAX consumers.
But still, it looks as though many additions such as GBS, B&T, and other webservices have been added without any discussion. So why not ?
Comments ?
-- Henri-Damien LAURENT
-- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin