I've been looking into the batch download workflows. Some issues and discussion are on these tickets:
http://projects.opengeo.org/CAPRA/ticket/779 <http://projects.opengeo.org/CAPRA/ticket/779> http://projects.opengeo.org/CAPRA/ticket/790 <http://projects.opengeo.org/CAPRA/ticket/790> http://projects.opengeo.org/CAPRA/ticket/791 The second ticket, #791, raises some issues with the spec for this API: What should happen when a user requests a batch of data, and they don't have access to one or more of the layers? I think there are a few things we should fix, at each layer of the stack, with proposed priorities: Java: The java REST process could return a 401 in this case. [Critical] Django: We could fix up the map_download and batch_layer_download views in Django to do security checks on the layers before issuing the request. * map_download is called with a map_id. It could filter out unreadable layers from the layers it requests from the batch process [major, to avoid bad user experience] * batch_layer_download gets a list of layers. I don't know whether it would be better to return a 401 or some other error in this case, or to proceed with the unreadable layers filtered out. [minor, can hide on the UI layer] I think this comes to another question about our public HTTP interface. I'm bringing this up primarily to raise the question of what to about it in the short term, but also because it has implications for what will be our API. JavaScript, Templates We could disable the 'select' checkbox on the Data Search page for layers that aren't Readable. [major, to avoid bad user experience of trying to get inaccessible batches and dealing with error handling] The 'download.html' template for batch downloading maps could notify the user whether layers in the map aren't readable and tell them that they won't be included in the batch. [minor, UI polish] Any thoughts? -- Sebastian Benthall OpenGeo - http://opengeo.org
