hampelm
commented
9 years ago I think a mid-term solution would be to support some less-than-beautiful parameters in the URLs. I was thinking along the lines of [vacant-or-abandoned][yes][color]=blue which could get parsed neatly by qs. Super pragmatic and explicit. All the settings are right now. It's real obvious what causes what.
Thinking about implementation of the cleaner solution. The client could build a stylesheet or the relevant params, send it in, get a token, and just include that token with all tile requests. If we hash stylesheets to generate the token we could get consistent tokens too. And the tileserver could keep them in a collection... would be pretty fast to just query it by id as needed.
We've discussed this a few times, but I don't think we've recorded things in one spot.
To date, the styles have been hard-coded in the tileserver and are generated from a template based on the form and tile parameters (question/answer). We've discussed an approach more like what cartodb uses, where the client can specify data parameters (in their case a SQL query) and a set of styles. That lets the tileserver become style agnostic, which is great for supporting custom map themes. It does add some coordination complications, though.
If the client specifies a stylesheet, then it needs to transmit it to the tileserver or point the tileserver to it. A simple approach is to pack the style info into query parameters, but then the requests become super gross, and we're not communicating style with a spec'd format, etc. If we do embed a whole stylesheet, or use POSTs, we're also sending a bunch of uncompressed, redundant data from the client to the server.
Instead, the client could transit the styles and other parameters only occasionally (when getting the tile.json, for example) and rely on the tileserver to save it temporarily and indicate an expiration. The client can track the expiration and repeat the process.
The client could also place the styles/parameters somewhere durable (like S3) and indicate the location in the tile.json request. We would require some the location to support some caching headers (probably ETag+If-None-Match), so the server isn't constantly making requests. For our current applications, this method introduces a new S3 write dependency on the dashboard, which I'm not excited about.
We could also continue to support templated stylesheets. Then the number of files needed would be much smaller (we get away with 2 right now), and we could hardcode a reference for the default styles in the dashboard app (eliminating an S3 dependency until we allow customization).