As a Beacon provider, I would like to ANNOUNCE the existence of my Beacon, to ensure that my lit Beacon is indexed by a Beacon registry and allow discovery. The way I see it we have three options: Static, Crawler, Announce
1. Static Discovery: beacon-registry can be bootstrapped with a static list of beacon peers
2. Crawler Discovery: A dynamic list of peers is built for a beacon-registry using a beacon-crawler3. Announce API Discovery: A beacon-server is configured on bootstrap/startup with a default {user-configurable} endpoint/token to allow the beacon to register itself with a beacon-registry/registries.
The last option would be, IMHO a more scalable solution.
Just an idea discussed with @mcupak and @juhtornr.
It would also open up future mechanisms that allow Beacons to transmit other meta-meta information, e.g. Heartbeat health-checks, Usage metrics, Last data updates, etc.
I have always imagined we'd be creating a model where a crawler crawls,
but would only find/register Beacons that announced themselves
I guess one could argue this is redundant, but one could announce OFF
and well as ON, which would take care of some uncertainties in the
crawling only approach. The announce only approach puts a large burden
on the Beacon to make sure it announces itself to all relevant passive
registries.
Tony
Susheel Varma wrote:
As a Beacon provider, I would like to ANNOUNCE the existence of my
Beacon, to ensure that my lit Beacon indexed by a Beacon registry and
allow discovery. The way I see it we have three options: Static,
Crawler, Announce
1. Static Discovery: beacon-registry can be statically configured at
startup with a list of beacon peers
2. Crawler Discovery: A dynamic list of peers is built using a
beacon-crawler
3. Announce API Discovery: A beacon-server is configured on
bootstrap/startup with a static enpoint/token to allow the beacon to
register itself with a beacon-registry.
The last option would be, IMHO a more scalable solution.
Good point. I think both the crawler and announce options could co-exist and not mutually exclusive. Just trying outline what should be default out-of-the-box.
Yes, the beacon-server would need to announce itself to any or all beacon-registries on startup.
I'm not sure it is a huge burden, but I would add that it would also mean that a Beacon provider would have more control over which beacon-registries their beacon can be registered to and any other beacon aggregators upstream
@susheel commented on Mon Oct 16 2017
As a Beacon provider, I would like to ANNOUNCE the existence of my Beacon, to ensure that my lit Beacon is indexed by a Beacon registry and allow discovery. The way I see it we have three options: Static, Crawler, Announce
1. Static Discovery: beacon-registry can be bootstrapped with a static list of beacon peers 2. Crawler Discovery: A dynamic list of peers is built for a beacon-registry using a beacon-crawler 3. Announce API Discovery: A beacon-server is configured on bootstrap/startup with a default {user-configurable} endpoint/token to allow the beacon to register itself with a beacon-registry/registries.
The last option would be, IMHO a more scalable solution.
Just an idea discussed with @mcupak and @juhtornr.
@susheel commented on Mon Oct 16 2017
It would also open up future mechanisms that allow Beacons to transmit other meta-meta information, e.g. Heartbeat health-checks, Usage metrics, Last data updates, etc.
@antbro commented on Mon Oct 16 2017
Are numbers 2 and 3 mutually exclusive?
I have always imagined we'd be creating a model where a crawler crawls, but would only find/register Beacons that announced themselves
I guess one could argue this is redundant, but one could announce OFF and well as ON, which would take care of some uncertainties in the crawling only approach. The announce only approach puts a large burden on the Beacon to make sure it announces itself to all relevant passive registries.
Tony
Susheel Varma wrote:
@susheel commented on Mon Oct 16 2017
Good point. I think both the crawler and announce options could co-exist and not mutually exclusive. Just trying outline what should be default out-of-the-box.
Yes, the beacon-server would need to announce itself to any or all beacon-registries on startup.
I'm not sure it is a huge burden, but I would add that it would also mean that a Beacon provider would have more control over which beacon-registries their beacon can be registered to and any other beacon aggregators upstream