Ideas for testing WoTC

gistfile1.txt

approach 1:
[07:50:09 AM] <xor-freenet>	Ademan: as i'm one of the paranoid kind, here's an idea i've had which could be used both to demonstrate how to use the WoT-Client (let's call it WoTC :), and to validate whether it works correctly:
[07:52:14 AM] <xor-freenet>	Ademan: have a mode of operation where it uses java serialization to dump the received data to disk, in the following layout: directory "Identities" contains files "$identity_id.wot-identity"; directory "Trusts" contains files "$trust_id.wot-identity", directory "Scores" contains files "$score_id.wot-identity" .... where $identity_id, $trust_id and $score_id are just the value of Persistent.getID() of the objects
[07:53:55 AM] <xor-freenet>	Ademan: that would nicely with synchronization: overwrite all files by ID, then have do for(all files) { if(file.versionID != currentVersionID) delete() }
[07:54:09 AM] <xor-freenet>	Ademan: and also with individual events: just overwrite file by ID  (or delete if the object was deleted)
[07:54:20 AM] <xor-freenet>	Ademan: so it would be a basic example of how a client application could store the data
[07:55:54 AM] <xor-freenet>	Ademan: additionally, if we implement a custom writeObject() at both WoT and WoTC, i.e. use the mode of operation where serialization is independent of the class names, then those files would be compatible to WoT's deserialization code.  or you just keep the same package/class names.   then the WoT-side tool wotutil.sh could receive a mode of operation where it compares the aforementioned Identities/Trusts/Scores directories of a WoTC dump to its 
[07:55:54 AM] <xor-freenet>	own database.
[07:56:59 AM] <xor-freenet>	Ademan: so one could do a test run such as:  1) run WoT + WoTC to obtain a WoTC dump.    2) disconnect the internet to ensure that all WoT events are flushed to WoTC before shutting down WoT   3) shut down both   4) use the wotutil tool to validate that WoTC has received&parsed all data from WoT correctly
[07:57:48 AM] <xor-freenet>	Ademan: the same could also be done by keeping the db4o code in WoTC, but i suppose we both agree that this would be too heavy. java serialization on the other hand is pretty lightweight and doesn't require any libs
[07:59:12 AM] <xor-freenet>	Ademan: and WoT already does have java serialization code for Identity/Trust/Score, it uses that to "hide" old versions of the objects inside of db4o for the event-notifications purposes. ("hide" = store them in a way which ensures that db4o queries for the "regular" objects won't see the old copies)
[08:02:12 AM] <xor-freenet>	Ademan: (sorry, my filename examples above used the ".wot-identity" extension for all as a copy-paste mistake, i of course meant ".wot-trust" / ".wot_score" for the latter ones)

approach 2:
[04:20:57 AM] <xor-freenet>	Ademan: btw a more simple approach of test code for it would be: disconnect from WoT, reconnect, and compare whether the new synchronization matches the current local database 100%.   however that wouldn't catch all bugs in the synchronization code itself.

approach 3 (new idea, most sophisticated one probably):
WoT contains a unit test which runs a full node to load WoT, and tests subscriptions AND the FCP client reference implementation:
   test/plugins/WebOfTrust/SubscriptionManagerFCPTest.java
you could adapt this class in WoTC to load *both* WoT and WoTC, and then test WoTC's state against the WoT database.