better storage for dive log and pictures

[Robert C. Helling]

On 22 Aug 2014, at 14:04, Willem Ferguson <willemferguson at zoology.up.ac.za> 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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140822/2379fabc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140822/2379fabc/attachment.sig>