From our Telegram chat:

Luke Stokes, [Jul 20, 2018 at 12:30:20 PM]:
Looking at this and discussing it now. Curious your thoughts on having a seperate table just for endpoint discovery? I'm getting a little pushback in terms of the workflow for a wallet to download all the data just to get the endpoints is a bit much. We created this file (updated every 10 minutes) to help: https://eosdac.io/topnodes.json

but I'm curious your thoughts on using multiple tables with straight data instead of just one json file

we also craated https://eosdac.io/topbps.json (also updated every 10 minutes)

on chain is a much better approach, for sure, but having everything in json may not make sense if someone just wants the nodes

Scott (anyx), [Jul 20, 2018 at 12:32:15 PM]:
Not really sure a seperate table is needed; you could parse the json from the producerjson table and grab as many endpoints as you need. 🙂
I briefly explained in the post why I don't think mutliple tables is the best idea; the BP standard is likely to change over time (possible rapidly), and validation should be clientside.

Luke Stokes, [Jul 20, 2018 at 12:34:06 PM]:
I only see this:

as well as allow quick changes to the BP standard format without a contract update.

But not much mention of the downsides of multiple tables (one for nodes, contact info, etc)

Maybe staying in json for now makes sense to keep a fluid, dyanmic standard as it's developed, but more and more I'm thinking we should be taking RFC approaches to do the hard work up front of defining a set standard

instead of assuming it will change later (and thus lead to breaking apps)

Scott (anyx), [Jul 20, 2018 at 12:36:20 PM]:
The big downside for multiple tables (at this current time) is the standardization efforts. Right now it just takes a json blob, and external validators can determine the convention.

In my opinion the transition to this will be much easier than conforming to a new standard, and we can change things over time if desired.

It's literally a one-liner cleos command to put your bp.json file into this table, so hopefully this gets traction.

Luke Stokes, [Jul 20, 2018 at 12:38:30 PM]:
What about the costs associated with wallets and apps having to change things, potentially multiple times? If they are pulling json files now, then they change to pull on chain then later they change to pull from individual tables once a standard is defined. In the meantime, how do we decomission old, legacy approaches? that could prove to be quite difficult. There is a cost associated with supporting approaches now which may become legacy in the future.

Scott (anyx), [Jul 20, 2018 at 12:39:08 PM]:
This is true regardless of using seperate tables while the standard is changing

Luke Stokes, [Jul 20, 2018 at 12:41:37 PM]:
I think that's kind of my point: Wouldn't it be better to do the work of figuring out a standard first? That way we have fewer changes all around and we remove one change in this cycle: pull json from web, pull json from chain, pull data you want from chain

(btw, I'm partially pushing back just based on push back I got from my own team. I think your idea is a great improvement on what we're currently doing)