The CCE3 test has moved to test version 3.98!!The Primecoin explorer is now running 3.98. The other explorers should be switched over soon.
New in this version:
Complete database integrity and automated recovery system
Complete removal of all per coin custom coding in the modules.
General clean-up and tighter code. Started basic code comment documentation.
***Database integrity and automated recovery system****I believe I have finally devised a system to squash those orphan critters.
1. There is now a 30 second delay between block height acquisition and querying the daemon for block/transaction information.
So far it looks to have improved the situation greatly, all the test explorers have been running that way for a couple of days. The only orphan to muck up the system was in the Primecoin explorer this afternoon.
This is OK, because the Primecoin test explorer is now running with 3.98 and it can now detect and squash those dam orphans with extreme prejudice.
2.At first I was going to add a third module to perform integrity checks, but have since incorporated it into the dbloader module. The integrity check will not be on a cron tab, but rather will run every so many blocks configurable in the cce3 config file.
The integrity check compares the block hashes in the database (from the last check/back-up to present database height) to what the daemon currently reports the hash to be. If a non matching hash is found, it then triggers the orphan killer function..err..automated recovery function.
The recovery function drops and recreates the database with the last backup. The database backup is always clean as the integrity function only dumps a database backup if the database has all matching hashes to what the daemon currently reports.
The transaction function can also call the orphan killer..I mean recovery function, if a transaction input has a prev_out tx that does not exist (A transaction that is part of an orphan block).
The other advantage to this system is always having recent database backup, depending on how many blocks are set in the config file.
*Complete removal of all per coin custom coding in the modules.*All custom code and coin parameters have been moved to the database. dbloader and the web server are now completely generic modules that can run any coin (In theory
) without customization. The config file consists of four lines.
database name
database user
database password
Block count (Determines how often the integrity check is run)
Everything else is set in the utility table of the database.
Development should start becoming faster as the logic coding is pretty much finished and in late beta.
Next up:One last major bug to squash. This is not a logic or coding bug, but rather a server set-up issue. If somebody requests a address ledger with a large amount of transactions (1000's) and then navigates away before the ledger shows up, the server gives a 107 error and basically needs to be killed by a level 9 kill. If not killed it will not serve any more connections and wait forever for the session to connect.
The ledger is very fast and only takes more then a second or two when dealing with extremely long ledgers. Even then it is rarely longer then 10 seconds or so.
Developers message box. The framework is in place and it should be ready with version 4. I will give access to this system as soon as it is ready to the developers whose coins are currently on the test server.
I still have to decide on how I want to handle market tickers. Each market has its own API and it looks like it could be a pain to accommodate. Perhaps I will need to get the information from some of the coin valuation sites that use CCE as an information source.
A few technical specifications on the project so far:CCE3 consists of two python modules (dbloader and webserver), one config file and a database with 6 tables ranging from 6 columns to 33 columns (utility, which only consists of one row). There are also the normal web files: css, robots.txt and icon files.
The two python modules have a combined total of 865 lines of code(including white space). I set out to make CCE3 light and efficient and hope I have accomplished this goal.
Web serving is based on CherryPy and Apache2 using the mod_rewrite module. Apache serves the static files, while Cherrypy serves the dynamic content. More then likely this set-up will change, with CherryPy still being the prominent web serving system.
As I head into version 4 and look at version 5, I need site admins to start giving me thought on how you would the the API to work. Version 5 is all about the API.
The development cycle on Version 4 is expected to be short, so do not miss out on your chance to help shape CCE3 API.
