CraftCoin is on CCE. This coin is has been created to be used by the Minecraft game community.
crc.cryptocoinexplorer.com
Topic: CryptoCoin Explorer - Coin Block Explorers. - page 5. (Read 30817 times)
A question the the users of the APIs on CCE:
What if I were to make subscription service that would send a JSON request containing the information commonly used every time a new block comes on the network for that explorer.
For Example:
PPC has a new block on the network. This triggers a database update. How about if it also sends out to the subscribed, a JSON request containing the new blocks height, difficulty, reward (when possible), network hash rate (again when possible) and other information determined by the dialogue here?
OR
Make it like a LP, where the explorer will send out a "ping" of sorts when a new block comes on the network and your sites can then request the information needed?
This would cut down considerably on the network "chatter" as no new information is available until a new block comes on the network and the explorer has stored the data.
Also, as mentioned above, I also need to know what other information your sites use. Regardless of how and when the LP or auto send work out, I still want to make an API that will send the information commonly needed eliminating the need for multiple API calls.
What if I were to make subscription service that would send a JSON request containing the information commonly used every time a new block comes on the network for that explorer.
For Example:
PPC has a new block on the network. This triggers a database update. How about if it also sends out to the subscribed, a JSON request containing the new blocks height, difficulty, reward (when possible), network hash rate (again when possible) and other information determined by the dialogue here?
OR
Make it like a LP, where the explorer will send out a "ping" of sorts when a new block comes on the network and your sites can then request the information needed?
This would cut down considerably on the network "chatter" as no new information is available until a new block comes on the network and the explorer has stored the data.
Also, as mentioned above, I also need to know what other information your sites use. Regardless of how and when the LP or auto send work out, I still want to make an API that will send the information commonly needed eliminating the need for multiple API calls.
I am for this - I assume I would need to have a callback script or something to accept the JSON push?
A question the the users of the APIs on CCE:
What if I were to make subscription service that would send a JSON request containing the information commonly used every time a new block comes on the network for that explorer.
For Example:
PPC has a new block on the network. This triggers a database update. How about if it also sends out to the subscribed, a JSON request containing the new blocks height, difficulty, reward (when possible), network hash rate (again when possible) and other information determined by the dialogue here?
OR
Make it like a LP, where the explorer will send out a "ping" of sorts when a new block comes on the network and your sites can then request the information needed?
This would cut down considerably on the network "chatter" as no new information is available until a new block comes on the network and the explorer has stored the data.
Also, as mentioned above, I also need to know what other information your sites use. Regardless of how and when the LP or auto send work out, I still want to make an API that will send the information commonly needed eliminating the need for multiple API calls.
What if I were to make subscription service that would send a JSON request containing the information commonly used every time a new block comes on the network for that explorer.
For Example:
PPC has a new block on the network. This triggers a database update. How about if it also sends out to the subscribed, a JSON request containing the new blocks height, difficulty, reward (when possible), network hash rate (again when possible) and other information determined by the dialogue here?
OR
Make it like a LP, where the explorer will send out a "ping" of sorts when a new block comes on the network and your sites can then request the information needed?
This would cut down considerably on the network "chatter" as no new information is available until a new block comes on the network and the explorer has stored the data.
Also, as mentioned above, I also need to know what other information your sites use. Regardless of how and when the LP or auto send work out, I still want to make an API that will send the information commonly needed eliminating the need for multiple API calls.
Nice, a block explorer with push. I think it's a good idea for sure.
A question the the users of the APIs on CCE:
What if I were to make subscription service that would send a JSON request containing the information commonly used every time a new block comes on the network for that explorer.
For Example:
PPC has a new block on the network. This triggers a database update. How about if it also sends out to the subscribed, a JSON request containing the new blocks height, difficulty, reward (when possible), network hash rate (again when possible) and other information determined by the dialogue here?
OR
Make it like a LP, where the explorer will send out a "ping" of sorts when a new block comes on the network and your sites can then request the information needed?
This would cut down considerably on the network "chatter" as no new information is available until a new block comes on the network and the explorer has stored the data.
Also, as mentioned above, I also need to know what other information your sites use. Regardless of how and when the LP or auto send work out, I still want to make an API that will send the information commonly needed eliminating the need for multiple API calls.
What if I were to make subscription service that would send a JSON request containing the information commonly used every time a new block comes on the network for that explorer.
For Example:
PPC has a new block on the network. This triggers a database update. How about if it also sends out to the subscribed, a JSON request containing the new blocks height, difficulty, reward (when possible), network hash rate (again when possible) and other information determined by the dialogue here?
OR
Make it like a LP, where the explorer will send out a "ping" of sorts when a new block comes on the network and your sites can then request the information needed?
This would cut down considerably on the network "chatter" as no new information is available until a new block comes on the network and the explorer has stored the data.
Also, as mentioned above, I also need to know what other information your sites use. Regardless of how and when the LP or auto send work out, I still want to make an API that will send the information commonly needed eliminating the need for multiple API calls.
I have rebuilt both the daemon and explorer databases for WDC and it appears to have cleared the issue.
I will continue to monitor the situation.
I will continue to monitor the situation.
WDC chain stop at June 22. seems something is down or not synching correctly. should have lots of block since that time at 15 seconds each.
the other explorer for WDC is also down so, I have no way to see the chain as I'm looking around at how clean the coins are this is on my list of check.
BTW great job for the explorer work great for other coins.
One feature I would like is something to help find orphan. where a block has 2 next. an example for Bitcoin is http://blockchain.info/orphaned-blocks this is where 51% attack can have occur and for ALT coin this is the most likely attack so anyone should be able to see it in the chain. (i can also see a simplified indication that just an icon when the next is multiple for a block and show the list of block as usual in batch of 20-50- with icon on those specific block ...) in fact should not have much when no attack occur or be in insta-mine mode.
the other explorer for WDC is also down so, I have no way to see the chain as I'm looking around at how clean the coins are this is on my list of check.
BTW great job for the explorer work great for other coins.
One feature I would like is something to help find orphan. where a block has 2 next. an example for Bitcoin is http://blockchain.info/orphaned-blocks this is where 51% attack can have occur and for ALT coin this is the most likely attack so anyone should be able to see it in the chain. (i can also see a simplified indication that just an icon when the next is multiple for a block and show the list of block as usual in batch of 20-50- with icon on those specific block ...) in fact should not have much when no attack occur or be in insta-mine mode.
Well, it looks like the same daemon error has popped up before at this point:
Code:
worldcoind: main.cpp:917: unsigned int GetNextWorkRequired(const CBlockIndex*, const CBlock*): Assertion `pindexFirst' failed.
This is with a fresh git clone and compile today.
I will look further into it, but if it is a daemon problem i will need an official git source to clone and compile to fix the issue.
WDC chain stop at June 22. seems something is down or not synching correctly. should have lots of block since that time at 15 seconds each.
the other explorer for WDC is also down so, I have no way to see the chain as I'm looking around at how clean the coins are this is on my list of check.
BTW great job for the explorer work great for other coins.
One feature I would like is something to help find orphan. where a block has 2 next. an example for Bitcoin is http://blockchain.info/orphaned-blocks this is where 51% attack can have occur and for ALT coin this is the most likely attack so anyone should be able to see it in the chain. (i can also see a simplified indication that just an icon when the next is multiple for a block and show the list of block as usual in batch of 20-50- with icon on those specific block ...) in fact should not have much when no attack occur or be in insta-mine mode.
the other explorer for WDC is also down so, I have no way to see the chain as I'm looking around at how clean the coins are this is on my list of check.
BTW great job for the explorer work great for other coins.
One feature I would like is something to help find orphan. where a block has 2 next. an example for Bitcoin is http://blockchain.info/orphaned-blocks this is where 51% attack can have occur and for ALT coin this is the most likely attack so anyone should be able to see it in the chain. (i can also see a simplified indication that just an icon when the next is multiple for a block and show the list of block as usual in batch of 20-50- with icon on those specific block ...) in fact should not have much when no attack occur or be in insta-mine mode.
Gldcoin daemon crashed, I have restarted it and the explorer is caught up.
Thank you for letting me know.
Robert
Thank you for letting me know.
Robert
GLD CCE stop counting blocks.
GLD CCE stop counting blocks.
How about a phenixcoin explorer? Thank you!
Looks like its downloading the blockchain again, thanks bud! Sending you 25 FRK for your service.
Take a look at the PM I sent you. I need you to check the block chain and make sure something odd is not happening.
Looks like its downloading the blockchain again, thanks bud! Sending you 25 FRK for your service.
Hey bud, looks like the FRK Explorer is about 2k blocks behind.
Can anybody suggest a GOOD guide to making dynamically generated web pages mobile phone friendly?
There are plenty of guides out there, but I would like suggestions from anybody who has had to use one and found it worked great.
I figure if I am going to build from the ground up, this would be the time to make the explorers mobile phone friendly.
There are plenty of guides out there, but I would like suggestions from anybody who has had to use one and found it worked great.
I figure if I am going to build from the ground up, this would be the time to make the explorers mobile phone friendly.
Some of the internal changes, or should I say a new block explorer
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.
It's a problem of apache-mod-fcgid, but not fastcgi. Normal fastcgi implementation should reuse threads instead of restarting them.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.
Try nginx & spawn-fcgi, this should be much faster. Also, it has smaller memory footprint.
I most definitely will.
My thoughts behind Cherry.py were along the lines of using a web framework/server written in the same language as the main application, might give an advantage.
The learning curve would be shorter also.
After some thought, it seems less likely the case and perhaps going with a more established framework/web server would be a better idea.
I apologize for the downtime this morning.
I guess this is what I get when I decide to sleep in one morning.
The traffic and I/O pattern just before CCE server 1 went down follows the pattern that happens during an attack.
Add to the list of things to add during the explorer rewrite
Anyway, all the explorers are back up.
I guess this is what I get when I decide to sleep in one morning.
The traffic and I/O pattern just before CCE server 1 went down follows the pattern that happens during an attack.
Add to the list of things to add during the explorer rewrite
Anyway, all the explorers are back up.
Thanks, I couldn't find BBQ on CoinChoose this morning
Keep up the great work!
I apologize for the downtime this morning.
I guess this is what I get when I decide to sleep in one morning.
The traffic and I/O pattern just before CCE server 1 went down follows the pattern that happens during an attack.
Add to the list of things to add during the explorer rewrite
Anyway, all the explorers are back up.
I guess this is what I get when I decide to sleep in one morning.
The traffic and I/O pattern just before CCE server 1 went down follows the pattern that happens during an attack.
Add to the list of things to add during the explorer rewrite
Anyway, all the explorers are back up.
Some of the internal changes, or should I say a new block explorer
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.
It's a problem of apache-mod-fcgid, but not fastcgi. Normal fastcgi implementation should reuse threads instead of restarting them.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.
Try nginx & spawn-fcgi, this should be much faster. Also, it has smaller memory footprint.
I just wanted to add, that I am not criticizing John Toby or the ABE project in the least.
John has been slowly moving in this direction himself with the reading of the memory pool to preload transactions.
What I am proposing was not possible until recently, and ABE has proven itself a cornerstone in the alt-coin community.
I am sure the John will improve/make a better version ABE that will give the new CCE explorers a run for the money, his programming skills are far more advanced then mine.
John has been slowly moving in this direction himself with the reading of the memory pool to preload transactions.
What I am proposing was not possible until recently, and ABE has proven itself a cornerstone in the alt-coin community.
I am sure the John will improve/make a better version ABE that will give the new CCE explorers a run for the money, his programming skills are far more advanced then mine.
Jump to: