storing pictures

[Guido Lerch]

Hi Dirk,

I¹ve put some thoughts into this. Not an easy topic as people might have
very individual requirements on this topic.
I suggest to take a step-wise approach, determining who would benefit
quickly depending on the complexity of the
implementation.

Let me explain my case.
* I love to take films and pictures
* I¹d like to assign them to dives
* I¹d like to use my mouse to add or delete them (have patches for this
already)
* I¹d appreciate if the loading doesn¹t take too long (no idea on how to do
async loading yet with threads but would be interested to dig into)
* I would like to have them stored in a  way I can access them from
different computers
* I do NOT expect them to load on mobile.
>From my perspective, implementing a V1, the easiest is to allow managing
pictures ³locally² in the way I send a few test
patches already. 
I don't know how Google drive or Box work in detail but I know with DropBox
I can synchronise my pictures across computers
and even on my iPhone.

If we allow the copy process from the source medial (SD card for example) to
a local DropBox location we already have achieved a lot.
I have the patches running with the last master and it works very nicely.
Files are copied automatically during the loading,
the new location is stored based on the user preferences. Images that are
used in multiple dives are not being physically
deleted on delete. If the preference to manage images is switched off images
are not deleted physically either and last
but not least, images are not deleted if the managed location has changed.

More comments below

Guido

From:  subsurface <subsurface-bounces at subsurface-divelog.org> on behalf of
Dirk Hohndel <dirk at hohndel.org>
Date:  Thursday 22 October 2015 14:08
To:  Subsurface Mailing List <subsurface at subsurface-divelog.org>
Subject:  storing pictures

> So I've been thinking about this for a while and I'm not sure what we do
> right now is the right thing after all.
> 
> So when a user adds pictures to their dive file, the dive file itself
> should contain information how to find the picture and (possibly?) a
> thumbnail of the picture (so if the picture isn't available for whatever
> reason, we can at least show a thumbnail.
> 
> So what does "information how to find the picture" mean?
> 
> - simplest case, it's a file:// url - i.e., where on my local computer
> - of course it has a hash which allows us to find it again if it was moved
> 
> But Subsurface should have a preference option that allows the user to
> specify a network base way to store pictures as well
could be done with radio buttons like O store locally O store remotely (e.g.
unc path)
> 
> - cloud storage: pictures are no longer stored as part of the users'
>   branch in the git repo - that makes remote operations over super
>   slow/bad networks harder and makes the first sync take forever.
>   Instead the cloud storage should allow users to upload their pictures
>   directly into their picture directory on the cloud server and then to
>   download them "on demand" (i.e., if the user clicks on a picture to see
>   the full sized version) - but of course look for a local cached copy,
>   first. So if I open my repo on my phone it only downloads the picture if
>   I tap on it (pictures currently aren't implemented there, anyway).
Can¹t comment on this as I am not experienced enough
> - Dropbox / Google drive / other shared storage mechanisma: allow in the
>   preferences to tell Subsurface how data can be uploaded / downloaded.
>   This can be as easy as a subdirectory of the "magic directory" that is
>   used for this cloud data storage. And then use hash-based names to find
>   the pictures there.
This is what I played with
> 
> Is this reasonable? What am I missing? I know that Guido has started to
> look into this, as has Robert... please comment / make suggestions how the
> idea can be improved.
> 
> I want pictures to be easy to get to from any device, but I don't want
> them to bloat the git repository as they do today.
> 
> /D
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151026/db685abd/attachment.html>