openooh / screen-id Goto Github PK

Flesh out proposal and pros/cons of trying to namespace existing IDs

This proposal allows 1 or more screen registries, and allows a screen owner to decide who and where their screen registry is.

The screen registry provides a discoverable data set of screens that the screen owner wishes to make discoverable

Let's say we have 3 objects

Screen
Screen Owner
Screen Registry

Screen owner decides "who/where" is the screen registry for their screens by creating a special DNS TXT record on their domain that can be queried

This TXT record contains a pointer to the DNS Endpoint of the Screen Registry that maintains the data for their screens

For instance coolooh.com may have a TXT record like OPENOOH_REG=coolooh.myprovider.com/open-ooh-registry

This registry contains a set of interfaces that allow programattic partners to query it for data about coolooh.com's screens

When CoolOOH goes to sign up for Some SSP they simply provide their company DNS name - Based on this, the SSP can query assets for this company

The standard we would then need to develop is

• What are the query interfaces
• What is the format of the data returned?

Then For any screen, they can be namedspaced with the name of the org that owns the screen. com.coolooh.{someUUID}

The other great thing about this is, given any screen id like com.coolooh.{someUUID} an SSP or a DSP can discover information about that screen by querying the TXT record for coolooh.com and finding the Screen Registry service that contains the data

What happens when screen status changes?
We can rely simply on HTTP status codes when you query the service for com.coolooh.{someUUID}

• Moved to another vendor (and now has a new ID?) - 301 Redirect
• 404 screen is gone forever
• 304 not modified if you send an eTag and just want to know whether or not any information about this resource has changed
• 503 could mean that the screen is offline

Etc. ETc.

Create a proposal fleshing out what a geo-based approach could look like