#9 "peer" used with varying meanings + bombing out if unknown

[Tomas Pospisek]

1) "peer" is being used with different meanings in the
documentation:
* sometimes it sounds as if it were the other host
* sometimes then the other user
* and finaly within the context of the db it means
email-address within the gpg key

2) I had interpreted that one could use whatever key-id
that gpg also accepts to konfigure a "peer". This is
not only a missinterpretation, but also makes the
daemon bomb out, without giving you an intellegible
error message:

$ dibs.py show_database
[...]

peerDatabase = {
{9176795A, { <-this
here is the gpg-key-id
email='user@somedomain.org',
comment='no comment here',
talk='passive',
listen='active',
host='host.somedomain.org',
port=6363,
remoteQuota=50000000 (bytes),
remoteStorage=0 (bytes),
localQuota=50000000 (bytes),
localStorage=0 (bytes),
{STORED_DATA =
}}

$ HOST=somedomain.ch dibs.py start_daemon
opening log /var/lib/dibs/.dibs/daemonLog at level 0

Connected by ('127.0.0.1', 48303) <- tunneling
in from outside
GET finished after receiving 0 files.
Handling incoming files:
opening log /var/lib/dibs/.dibs/logfile at level 0
Subject: <DIBS> DIBS ERROR

Command was '['/usr/bin/dibs.py', 'process_message']'.

Exception of type '<class exceptions.KeyError at
0x810c26c>': 'user.dibs@host.somedomain.org'.

Traceback:
File
"/usr/lib/python2.2/site-packages/dibs_lib/dibs_ui.py",
line 645, in ?
c.run(sys.argv)
File
"/usr/lib/python2.2/site-packages/dibs_lib/dibs_ui.py",
line 476, in run
d.ProcessMessage(file)
File
"/usr/lib/python2.2/site-packages/dibs_lib/dibs_main.py",
line 333, in ProcessMessage
eval(cmdString)
File "<string>", line 0, in ?
File
"/usr/lib/python2.2/site-packages/dibs_lib/dibs_main.py",
line 36, in StoreFileForPeer
if (len(dibsM.payload) > \ File
"/usr/lib/python2.2/site-packages/dibs_lib/dibs_database.py",
line 458, in RemainingQuotaForPeerOnOurMachine
peerRecord = self.peerDatabase[peer]
[etc.]

Again, the daemon should provide the user with an
intellegible error message and not a traceback or in
other words the exception should be caught, analysed
and being transformed into something a user can interpret.

Seeing that your current version in CVS is 0.99, I'm
guessing that you want to release a 1.0 version soon.
I'd suggest before releasing 1.0 to go through the code
and to look at the places where things can go wrong and
to put some useful feedback for the user in there.
Otherwise it's just very difficult to figure out what's
going wrong for the user.

Thanks,
*t