Make sure format from URL is working correctly and investigate all possibilities and make sure they are valid. Throw an error for bad formats. Also if format is supplied then take it as an override despite the request extention.
Currently tilelive-mapnik will throw an error, which windshaft intercepts and doesnt give a json. Unit tests prefer valid jason when a request is made, but without data. Not sure which one is better at this time.
I don't think modifying grainstore is worth while, instead make a wrapper including grainstore that encompasses all 3 inputs (grainstore/mml (millstone)/xml)
Take in local mml file with local datasource
Take in local mml file with remote datasource
Take in local mml file with remote zipped datasource
Take in remote mml file and treat it like a local mml file
Return HTTP header 204 with no payload when mapnik has no data for the tile. This in turn should/can be taken advantage of for user interface map libraries not to request a utf grid for that tile.
Reuse as much of grainstore as possible o allow allow non-database datasources to go through grainstore. Would be able to provide a remote zipped shape file and supply a .mss style without having to create a mml file.
Instead of taking the SQL sent as a request as a brand new sql, assume it is a wrapper to the existing SQL and allow queries like SELECT TOP 10 * FROM %TABLE% where %TABLE% is the subquery of the original SQL.
Make sure ODBC connections will correctly get put into the mapnik xml. Default mssql to ODBC and possibly add support for additional mapnik datasource/connections via plugins to Windwalker. For example using mssql-mapnik would be a simply nodejs package that windwalker would automatically know how to inject the input file where they need it.
Start off with ODBC and mssql and then include from a huge list of possible mapnik plugins that can be used.
This will determine rather or not to hide errors by default, user can always override though.
Look at standard if its normal to log errors or not with env variable, don't want to confuse people that it acts one way in dev and not the same way in production, with the exception of maybe security concerns (showing errors as a tile response)