consider solidifying tilesource API as a prototype

[tcql]

During some discussion in gis-devs slack, it was pointed out that not all tilelive Tilesource implementations have the full api (tilelive-mapnik implements getGrid, while tilelive-bridge does not. And API.md suggests that getGrid is standard for Tilesources).

It might be nice if we have a Tilesource function that stubs all expected methods on it's prototype, and rework existing Tilesources to inherit the prototype. This ensures that even if a source doesn't fully implement the Tilesource API, the stubs at least exist. I think this also solidifies expectations around what should be implemented by a custom Tilesource, and how to start building a custom Tilesource.

[tmcw]

(tilelive-mapnik implements getGrid, while tilelive-bridge does not. And API.md suggests that getGrid is standard for Tilesources).

I'd suggest that getGrid should not be part of the minimal tilelive API.

[yhahn]

Hmm, I understand the pains here. Some context:

• Not a huge fan of JS inheritance as a way of enforcing a spec,
• Tilelive "spec" is currently in somewhat of a discovery phase as the tile ecosystem has changed considerably since its inception. Per @tmcw's comment utfgrid's are a deprecated technology (replaced by vector tiles) and we've also seen more interfaces that require getTile inputs beyond z/x/y (retina? language support? other options?)

My take is to observe how our current generation of modules continue to adapt to the image => vector transition (with how raster tiles make it through a big question) and then to adjust our spec accordingly before looking to codify the spec further.