[Koha-devel] RFID reader in browser with data from Koha

[Dobrica Pavlinusic]

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_browser.html
>>
>> 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 at 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 at rot13.org
Unix addict. Internet consultant.             http://www.rot13.org/~dpavlin