On 22 Aug 2014, at 14:04, Willem Ferguson <[email protected]> wrote:
Hi, I don’t have anything to say at the moment about making the git storage more end-user friendly. But maybe some ideas about images: > It is probably wise to allow for remote storage of images. This means > that provision to view images from anywhere is not easily implemented > unless somthing like dropbox is used. I brought up URIs in the past as that sounded like a reasonable way to treat local files and remote files similarly. But maybe that is not necessary. As far as remote images are concerned, I would say support http addresses (and treat those as read only) and that’s as good as it gets. If the images are not on your hard drive, accessing them is always limited by network bandwidth. So it does not matter what kind of protocol is used. And with html, you can either make your own images available by running a small web server that serves them from some directory of some host you have access to or you use something like google+ or flickr or dropbox to store your images, they all provide you with URLs of your images. There might me one or two things to consider with authentication (when prompt for password, store it or not and if yes where etc). In that case, getting the URL into subsurface would require a good UI besides “enter the URL in this field”. At least something like “consider all images liked on the webpage with URL xyz with search depth n” and then we have to fight that some of those might be hidden behind some javascript. I don’t know. For that we could even make subsurface produce an index.html that contains links to all the images mentioned in you dive log (assuming some replacement of the local path with a URL component like /home/robert/public_html/diving_pictures/fish4711.jpg to http://myserver.example.com/~robert/diving_pictures/fish4711.jpg) As far as local images are concerned, we have to deal with the problem that the paths of an image could by very different on different machines that are used for the same dive log. Besides path translations of various kinds (like a local image dir base path) there could be a radical solution: Don’t even try to store the path to a file but rather a hash of the image and then (upon a request) build a local hash to path dictionary with a tree search on the local directories. Maybe a cryptographic hash is not exactly what we want as that changes under image transformation (size changes, photoshopping), maybe simply the time stamp of the image taken would be a better way of addressing images (given that diving pictures are probably all taken with a digital camera, that field should have a somewhat reasonable value and be sufficiently unique even taking into account not properly set camera clocks). Dirk asked for a brainstorm, this is what I came up with. Best Robert -- .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO Robert C. Helling Elite Master Course Theoretical and Mathematical Physics Scientific Coordinator Ludwig Maximilians Universitaet Muenchen, Dept. Physik print "Just another Phone: +49 89 2180-4523 Theresienstr. 39, rm. B339 stupid .sig\n"; http://www.atdotde.de
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
