Promisify tilelive and add extra context

tilelive is fundamentally a URI-based dependency container service, allowing separation between service implementation/instantiation and service consumption. Moving away from the rigid getTile(z,x,y) API would allow more diverse context parameters and non-tile services.

• A single “get” function with a single options object instead of individual parameters to handle implementation-specific functionality.
• Promises instead of callbacks, as Promises have now became widely spread, and the current Node (7) supports language-integrated constructs (async/await)

For example, getTile(z, x, y, callback(err, data, headers)) would be something like Promise<{data, headers}> getAsync({zoom: z, index: ind, extra1: ...})

For compatibility, tilelive should inject a rudimentary getAsync() (See injection lib), that only supports the basic {tile|grid|info} modes into the legacy tilelive sources. The auto-injected getAsync() would not support any of the magical customizations, such as parameters set on callback function. For that, the source would have to implement its own version of getAsync, e.g. tilelive-vector PR.

Immediate benefits of adding a single getAsync() function:

• ability to pass additional parameters through the stack callchain. E.g. language, licence, …
• ability to handle non-tile requests like snapshots (custom area of the map with the given width/height)
• ability to integrate related services using the same pipeline. For example, in Wikipedia, Kartotherian can get geojson for a specific area, and that same geojson could be used as an extra layer in the snapshot service. Another example - simple-style markers (pushpins) - request a given marker/color/icon size/scaling, and get back an image via the same chain, but with somewhat different params. The source instantiation will continue using the existing tilelive container, without the need to create a separate pipeline.
• ability to introduce an alternative (additional) way of addressing tiles - a single quad-based index instead of x,y coordinates

[mojodna]

👎 on Promises (at least until async/await is mainstream), especially since callback-driven interfaces can be adapted to work with Promises fairly easily.

👍 on options. tilelive-vector demonstrates the need for being able to wedge in custom parameters when requesting tiles w/ non-standard sizing, etc.

+0 on batching, since it already exists in a couple of different forms.

Can you elaborate on the quad-based index idea? z/x/y URLs are very common, so I’d be hesitant to move away from that without good reason.

I’ve implemented one mode of of batching w/ tilelive-streaming (tilelive itself has a different streaming interface that also supports batch operations).

One longstanding (slightly voiced) request I have is for getTile and putTile to support streams directly (included as an after-market enhancement in tilelive-streaming). I would love to be able to call src.getTile(x, y, z).pipe(res) to pipe a tile direct to an output response (possibly using multiple chunks). Most extant tilelive sources don’t read/generate chunkable output, but I think that’s a bad assumption to make.

[nyurik]

Tilelive.js as it stands now is about defining this implicit contract, and about assistance loading modules.

@rclark I so wish we can separate these two. API and dependency container are really two separate. unrelated things. And yes, stream functionality might not belong there either…

There is one fundamental problem that I cannot work around with the current code. Given an API implementation, like tilelive-vector, that uses an instance of another implementation (the backend), there is currently no way to pass parameters through the layers. I had to patch tilelive-vector itself to allow “context passing”. Without it, there is no way for a license key, user’s language, or any other information to be passed.

My getAsync polyfill library obviously does not address that, as it can only convert (opts) into {x,y,z}.