--- brodders@cwcom.net wrote:
Hi David!
----- Original Message ----- From: "David Freeman" david_freeman@rocketmail.com
--- brodders@cwcom.net wrote:
Migod! ALUG Library's...come back to life!
My<insert object of worship here (Linux torvolds, RMS, ESR, Steve
Jobs,
sarah michelle gella etc...)> it has come back to life, RUN!
:) poor poor linus .. like it!
Thanks :o)
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.
I never got around to ripping it a part. The problems are
- Based on assumptions a) People are honest
b) People will notice books have gone astray c) People will return books
yes. It's either that or it gets real difficult.
Complexity is all relative, what may seam complex can infact be simpified quite nicely when you take a different angle of attach.
Seriously, casual fraud is the only real threat - if people try to use the system at all, the system will know who's got what. From this stocktake data is available. The threat is that people just ignore the system, pass things around & it collapses into one big muddle. I don't know how we can stop this one.
Centralisation. As much as I like the idea of the Peer-to-peer networking technique it, like most ideas, is only applicable to certain tasks, and I believe this isn't one of those. I think a hybrid of peer-to-peer and centrailised systems much like napster would be a good solutions.
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.
In that case you haven't modelled the system properly. You can't
start
programming till you have a decent enough idea of how it will work.
incedentally I will have a modell created by mondays IRC.
excellent. Will it have pictures? I like pictures.
Would it be a model if it didn't have pretty pictures?
I may also model the relational scheme or I may do it as objects to be written in java.
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.
Yes. What happens to person B and C do they still remain at places
1
and 2 in the list? What if they ask for the book to be mailed to
them?
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."
See above.
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.
There needs to be a dead line for collection and for loans, but you would have modelled this in the functional requirements.
Why? This is at heart a stock control system, in the guise of stock tracking. If an item stays on a shelf for a month, does it need permission to stay there for another month? Is there actually a need to have controlled returns if we know where the item is? We do not have to model our system on anyone else's ideas of how libraries work.
Do we know who has the item? "who has book x?" "I gave it to the next person on the list at the last meet" "who was that <looks opn system>, so you gave it to john doe?" "yes, Joh do you have the book I gave you at the last meet?" "No I wasn't at the last meet" "So who got that book then?"
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?
Let me think on this one.
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.
see above comment
Ultimately - to be perfect the complexity of the solution must mirror the complexity inherent in the problem domain. Or, lop off minor complexities / degrees of freedom in the problem deliberately to straightjacket (= simplify) the solution. I actually sent myself to sleep a few weeks ago thinking about issues arising from trying to correct out-of-order borrowing & impacts on issued keys. Danger Will Robinson - don't go there! Let's make it simple.
Quite true, we need to simplify the domain of the problem into something sensible. As for the thoughts to goto sleep by, try desolved gas algorithms and gas phase modelling, great fun :o)
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).
Fine any DBMS should do the job, even access should work, if
designed
properly.
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).
And what are assumptions?
That everything is easy apart from the difficult bits. And, where it ain't easy, I hits it with this here hammer until it gets simple :)
I will have to confiscate your fine adjustment tool at the next meet. Every engineer knows that a large ajustable spanner works better, after all it has more uses than just bugdening something :o)
What I'm saying is that people can make things work - if the things are possible to work at all. So, explore what's more possible vs. what's less (or im)possible.
So basically you have ignored the one assumption which is safe to have "people are a problem"
This is based on a top-down development view which says "don't rely on things which can't be made to work". Idea is to identify the easy / practical route; this means proof-of-concept tests needed when going into new areas.
oh goody an interative development process.
Once a solution strategy is found possible, getting it working is through dint of effort; leg-work if you will. That's what the next bit is about - I needed a way of proving the solution strategy.
Makes sense.
TO be continued in the next message.
Thanks
D
First up I needed a model environment, so I put together a box networked to
=== message truncated ===
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/