POOL OPERATORS! A request...

[P_Shep]

Could you, between yourselves, sort out a standard JSON API interface.

K, thanks.

[P_Shep]

I'll expand a little...

Provide a standard output with basic info about the user/worker, MAYBE pool as well.

You can decide among yourselves what this 'basic info' is.

This isn't to replace your current APIs but to add something standard that apps can receive and not have to worry about writing X number of decoders.

Thanks

[P_Shep]

No desire to do this at all from anyone?

 

My suggested info:

API version
Current round duration
Current round shares total
Current round shares submitted
Current round estimated reward BTC
Current hash rate
Last activity
Confirmed BTC
Unconfirmed BTC
Total payout BTC
Last payout BTC
Last payout time
Payout threshold

[nibor]

p2pool is open source so you can do it yourself.
Also there would then be a reference implementation for others to copy..

[Inaba]

I'd be happy to implement something if it were agreed upon.

[Luke-Jr]

If someone wants to implement it for Eligius, feel free to email me for webserver access...

[enmaku]

I'll +1 this. I'm all about the infoporn and the sooner someone writes a standard for APIs the sooner I get my better quality infoporn. 

[[Tycho]]

AFAIR, slush was the first one to implement JSON API, so I just used same keys when possible in my version of API.
That's why it says "confirmed_reward" instead of just "balance".

[redditorrex]

Watching.
I would be nice, but it is somewhat irrelevant
But if someone wants to write up a standard MtRed would support it.

[DrHaribo]

I'd be interested in supporting this.

How similar are the APIs of Deepbit and Slush? Perhaps a standard can be based off of those.

[P_Shep]

Good to see my pro-active attempt gained some interest (Sorry if it was spammy!)

OK, how about something like this:
(We'll leave workers and previous blocks for later versions.)

block =
{
    "duration" = <seconds>,
    "shares_total" = <total shares submitted so far for round>,
    "shares_submitted" = <shares submitted by user (all workers)>,
    "reward" = <estimated reward for current round or actual reward for previous rounds in Satoshis>
}

user =
{
    "API" = 1.0.0
    "current_round" = {<active block (as defined above)>},
    "hash_rate" = <current hash rate in MH/s for all workers - implementation pool dependent>,
    "last_activity" = <last submitted share time in unix time>,
    "confirmed_reward" = <confirmed reward (>=120 valid blocks) in Satoshis>,
    "unconfirmed_reward" = <unconfirmed reward (<120 valid blocks) in Satoshis>,
    "total_payout" = <total amount of BTC payed out to user (could be reset by user? - up to pool)>,
    "last_payout_value" = <value of last payout in Satoshis>,
    "last_payout_time" = <time of last payout in unix time>,
    "send_threshold" = <min confirmed reward before auto payout in Satoshis. 0 for no auto payment>,
    "workers" = {<TBC>}
}

Some elements take from Slush here.

So to retrieve BTC info, the URL would be something like:
http://<pool>/api.php?key=<API key>&currency=btc
or
http://<pool>/json/btc/<API key>

Then namecoin stats would be retrieved separately.
No real need (that I can think of) for URLs to be common/deterministic, down to the pool operator I should say.
At my end, I'd just use the entire URL in Anubis and deal with the data, not try and form the url.

 

[Inaba]

https://bitcointalk.org/index.php?topic=83027.msg915200#msg915200