New subject: [Alug] ALUG Librarian stuff

9 Jun 2001


      Migod! ALUG Library's...come back to life!
OK so no-ones ripped a new one in the idea of a peer-peer ALUG Library. That's
nice; I  assumed we'd go that way so I've quietly been doodling around with
the concepts.
Have not thought about consequences of wandering people; don't think it's too
much of a problem insofar it's generic & will not go away. I'm for doing no
more than normal add-person, delete/edit person etc. Um? fine person? New joiners
give a sub which they get back when they go LESS losses? Could be expensive.
Perhaps a borrowing cap is in order. Another table... NOPE a new attributes
of the Person table; default say 4.
This might as well be a progress report on what I've done, so here goes.
Top level concepts as last reported + thoughts on this issue:
Are there any issues if item passed to wrong person. Example:
Person A has WonderBook which everyone wants. Person's B,C,D etc. request it.
B is at top of list.
At the next meet everyone is there except B. Oh dear  a ruck forms; A & book
disappear from view & when tussle clears D has made off with it. "Well, B had
their chance."
Is this legal? Don't see why not; B could well miss a meet & it seems fine to
me that someone else gets the book. For this to work, everyone must have been
issued a key to give A. That may mean another table for the confirmation keys
rather then finding a home for <the one key> in say the Transaction table.
Alternatively if it's NOT OK to passover B  what then? Perhaps C only should
be allowed to have the book, not D as decided in the tussle?
My instinct is that the more flexible the better; so I'd plump for "issue N
confirmation keys & let people decide for themselves". There are more arguments
around this area (the confirmation key is now effectively a person ID, so why
keep on scrambling it?) but overall I'm happy with this. It's more secure /
difficult to defraud this way.
Next up, db progress.
Postgres is wonderful, BUT as I had everything to hand to get going with MySQL
so I made a start using it (also I had another project which used MySQL).
Now when I make a start I explore problem areas. This ties in with my design
assumptions  which are that everything's easy - except for the problems. So
I want to know  what are the problems & where are they? Once these are conquered
I can go back to sleep (=base mode).
First up I needed a model environment, so I put together a box networked to
a PC. There's the server, here's the client <this included a big diversion fighting
various Linux distros; they didn't like the ancient embedded video on the server>.
MySQL goes in, fight with that. Many minor mistakes; finally import a test database
 for the other project; but principles established. Install MyODBC onto the
PC; that is a success.
Next up  how to actually do it? I want a RAD or sumfin'.
Access works well via the ODBC, but that's not PC. Hm. StarOffice 5.2! It sort
of works and crashes but it's just about usable; snag it it doesn't quite fit
MySQL nicely.
At this point I was going to make a start putting some default forms together.
OK not for the final system; they'll have to be over the web. But these are
1st shot functional screens to get things going; SO5.2 has a GUI editor all
drag'n'dropish with predefined stuff (fields, buttons, pull down lists etc)
& that's nice esp. when it accesses the remote test MySQL db and I see real
data in the fields on my PC. At that point I went on holiday & now it's now.
Be Warned  I'm not a coder (well not in the last 15 years).
Bye Bye for now!
Steve

Re: [Alug] ALUG Librarian stuff