"Wilfried Woeber, UniVie/ACOnet" <woeber@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