Pablo, thanks for the explanation. Here're a few comments: > ... concurrent access environment ...
I agree with you. In a REST context, this is a lot easier, because of statelessness. And who knows if there're any HDF5 files. All a user/application sees are resources and representations; no way of telling if it came from an HDF5 file... > Why HDF5/REST? > Answer 1: Because it gives great visibility/usability to our data. I'm with you on that one. > Answer 2: This is completely silly. Yes, if pushed to the extreme; but that's true for anything, isn't it? One of the nice things about HTTP is content negotiation. Yes, we should support the mainstream formats (JSON, XML), but there's room for others, such as, Avro. Another option is connection upgrade, which could be used to stream data over WebSocket. I'd be interested in your thoughts on the resource and URI structure, i.e., how (in-)convenient it is for the kinds of applications you're thinking about. The main challenge for us is to come up with something that's general, i.e., not specific to a particular application domain, and useful at the same time. Best, G. _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
