Dumping Fastcgi and using Cherry.py. One of the large advantages Cherry.py has over Fastcgi is the elimination of opening a new Python thread with every operation/request. This will make the explorer faster and lighter on resources. I also want to look into using Fastcgi/flup with Cherry.py. There are multiple ways to configure this and Cherry.py appears to be very flexible about it.
I am also looking at Mako templating.
At least at first, using PyMySql database API. I have found it to be very fast compared to the database API ABE uses. I also need to look at python Postgresql APIs and find the best one for this application.
With the current explorers there is too much interpretation of data with requests. I am sure Abe's developer had his reasons for storing data in machine friendly, close to the original data read from the block files. I, however, believe in the opposite approach. Why keep reinterpreting the same data over and over.
The new database structure will store everything in a human readable format. This will greatly reduce the number of tables and shrink the database.
The new explorers will no longer read and try to interpret the BLK files. I can get all the information needed from the daemons with a couple of small patches to the daemons. The main one being the commit/patch Balthazar uses on Novacoin to allow the daemon to look up and display any transaction, not just the ones in the wallet. The PPC and NVC commits (Thanks again Sunny and Balthazar) that allow the daemon to calculate network hash rates has been invaluable when calculating the split difficulty and targeting times of POS/POW.
The daemons in general give out much more information then in the past and I think the days of scanning BLK files are dying out.
I realize when first building a database, it will put a large amount of stress on the daemon. This is perfectly fine as I shut down web access when rebuilding databases anyway, and it is a rare occurrence (For the most part
). After the initial database build, the explorer will make a few requests, more depending on the number of transactions, every block as blocknotify is tripped.The purpose of the redesign is to make a lighter and faster explorer that only deals with information people need and stop calculating information people rarely use or understand. This will allow CCE to carry more coins using the current server(s) setup.
Secondary to my purpose, when the new explorers go open source, it will be very easy to adopt them to any coin. Because they get the data directly from the daemon there is no longer the need to try and tailor actual code to the block structure itself. Everything needed to make it work will be able to be done in the configure file.
Cosmetically, the sites will be separating the coins into the Home pages I mentioned above, completely solving the cluttering problem the home page suffers now. It also gives the appearance of a site tailored for the coin, as it will serve as an information center and another way for developers to communicate with the coin community's. The quick reference links and technical specs will help people out without having to hunt and search for these items.
Well, I have rambled on long enough, I will post as more information becomes available.
TLDR: A bunch of technical stuff and reasons for a ground up redesign of the explorers.
