The addition of guarded fields

"Wilfried Woeber, UniVie/ACOnet" <woeber at cc.univie.ac.at> writes
 * Well there are two sides to the game:
 * 
 * -a	you shouldn't mind changing someone else's data, if it is wellknown and
 *    	it can be implemented in a very streightforward manner. 
 * 	I never regard my objects in the DB as my personal "hands off"
 * 	property, but rather as shared info submitted to achieve a very
 * 	well-defined and well-understood goal.
 * 
 * -b	when and if it is not easy to describe, understand and implement, and
 * 	if the result would even possibly violate current rules, I'd propose
 * 	to push the issue further down the tree to have it resolved.
 * 
 * >- In oder to keep the database size under control, we should also implement
 * >  generating blocks again from individual entries in the database, but then
 * >  again I am fiddling with someone elses data, which I do not like at all .
 * ..
 * 
 * I'd appreciate getting a message proposing recombination of entries, or even
 * a pre-fabricated message(s) to accomplish this. Then I would generate or jus
 * t
 * check/update these things and submit them as an update. Once again, for me i
 * t
 * wouldn't be a privacy issue, but rather I like to know that things are going
 * to change. It could point me even to a local problem.

If a block was split, I would always mail the changes back to the person that
last changed the entry, but the thing I do not like is that people who keep
local databases for their information will then have to change their database
to reflect the split etc etc etc. That is the part I do not like.

-Marten