-------- Forwarded Message -------- Subject: Re: better storage for dive log and pictures Date: Fri, 22 Aug 2014 13:56:17 +0200 From: Willem Ferguson <[email protected]> Reply-To: [email protected] Organization: University of Pretoria To: Dirk Hohndel <[email protected]> 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
_______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
