Fwd: Re: better storage for dive log and pictures

[Willem Ferguson]

-------- Forwarded Message --------
Subject: 	Re: better storage for dive log and pictures
Date: 	Fri, 22 Aug 2014 13:56:17 +0200
From: 	Willem Ferguson <willemferguson at zoology.up.ac.za>
Reply-To: 	willemferguson at zoology.up.ac.za
Organization: 	University of Pretoria
To: 	Dirk Hohndel <dirk at hohndel.org>



On 21/08/2014 23:10, Dirk Hohndel wrote:

a) XML file storage is reasonably well understood. We have a default
directory on each platform and a scheme to create a default name.
We can set the default filename in the UI. One thing missing might be a
button that says "make current data file the default data file".


Please consider this brain storming. Maybe there are other, better
solutions? Post your ideas here. There was some discussion on trac
(http://trac.hohndel.org/ticket/669) including references to RFC1630 - I
don't think that's the complexity that we want (ignoring that this
standard is 20 years old). Instead I am looking for something pragmatic
and extensible that works both with XML and git storage, across all three
OSs (forget symlinks) and addresses common usecases.

/D

______

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. Most photographers have
collections of photos that run into the thousands and it is normally not
possible to have these on the regular computer all the time. Therefore
an offline source or a server is a more suitable answer. The question is
whether there is a large demand for image access away from one's normal
workstation. and I think not. Or let me put it this way: I think there
is a much larger demand for remote access of dive information than there
is for photos and it makes more sense to have one's photos in a standard
place all the time. The large size (20-45 Mb) of RAW images makes even a
remote server on the Internet less attractive. My suggestion:

1) Ensure reliable access of images located outside of the dive log
folder tree. My test manipulations indicate that most of this already
exists. What one does NOT want is a system where photographs themselves
(as opposed to their handles) are treated as part of the dive log and
its backup.
2) Focus on good integration of the dive log and its backup with copies
on more than one machine, merging and synchronising the dive log with
remote infrastucture and the access of the dive log from remote
localities. Personally, my feeling is that the HTML export of the dive
log in combination with smart phone access satisfies most of the needs
for remote access.
3) The question is to what degree do we need the ability to UPDATE the
dive log from many remote places?

Kind regards,
willem



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140822/61181cb4/attachment.html>