storing pictures

[Dirk Hohndel]

On Mon, Oct 26, 2015 at 06:53:50PM +0200, Guido Lerch wrote:
> 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.

Thanks for sharing your use case. Let's just make sure we all understand
that this is YOUR usecase, not necessarily the only target use case.

One thing I want to make sure we keep in mind is that I have a strong
preference for any solution that we have to be designed around OUR CLOUD
STORAGE. I don't mind supporting Dropbox et al as well, but we should
never suggest / prefer a proprietary backend over what we can do and any
person who so chooses can set up for themselves.

> 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.

You mean this "copy process" to be the Dropbox specific implementation of
the "upload pictures to the shared storage mechanism"?

> I have the patches running with the last master and it works very nicely.
> Files are copied automatically during the loading,

That's nice. That's something that is designed specifically for Dropbox.
As I said above - I want us to design a solution around our storage
backend. And then look into how to do this with other distributed storage
/ cloud solutions. Not the other way around.

> 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.

All nice.

> > 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

(and btw: I didn't literally mean file:// Url - I meant this to simply
indicate local storage)

> > - 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)

Sure, with Dropbox you could abuse the file path based storage.
But that's not what I wanted to discuss. I wanted to discuss how we do
this for Subsurface cloud - and then how that can be extended for other
services.

/D