Move ZEO conflict resolution log to client, include class name of conflicting object

(09:49:24 PM) Theuni1: J1m: looks like the storage server doesn't have too much information about the conflict when it logs it. Do you feel that it would be helpful if it logged the object's class name that was conflicting?
(09:49:55 PM) Theuni1: In that case I might dig deeper, but I have the feeling the code paths are too far away to do this without a serious performance penalty or restructuring.
(09:50:02 PM) J1m: I don't think the storage server should log anything about conflicts.
(09:50:30 PM) J1m: If it does now, which wouldn't surprise me, then I'd consider that a bug.
(09:50:52 PM) Theuni1: Hmm. Then there's a bit of buggyness there. :)
(09:50:57 PM) J1m: In general, I don't think servers should log events that are not their fault.
(09:51:12 PM) J1m: Could be, we often get logging wrong.
(09:51:21 PM) J1m: I know ZODB often does.
(09:52:01 PM) J1m: Jim's principal of information: present information to parties that can act on it.
(09:52:14 PM) Theuni1: Ok, so my task moves around a bit: the server shouldn't log that, but then I'd need to make sure that the client does because *someone* needs to log the info that there was a conflict.
(09:52:17 PM) J1m: If there's a conflict, it's a problem for the client.
(09:52:29 PM) J1m: Yes.
(09:52:32 PM) Theuni1: Does ZEO propagate the information that there was a conflict back to the client?
(09:52:44 PM) J1m: Of course, if you have the oid, you can get the class.
(09:52:50 PM) J1m: yes
(09:52:54 PM) Theuni1: alright then.
(09:53:18 PM) J1m: Getting the class is icky, especially on the server.
(09:53:26 PM) Theuni1: yeah, just doing that look up in that part of the code felt wrong right away
(09:53:32 PM) J1m: I'd rather the server not do that.
(09:53:48 PM) Theuni1: OTOH if the client has an oid that conflicted its probably cheap to get the class
(09:53:57 PM) J1m: yes
(09:54:36 PM) ***Theuni1 goes off writing a bug

which is how this ended up here.