support for images per dive

[Dirk Hohndel]

On Jan 4, 2014, at 4:16 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:

> we had a quick discussion on irc with tomaz and thiago and we ended up
> with some suggestions on this topic.
> 
> in any case we may need to change the default subsurface format.
> 
> thiago suggested zipping the XML and photos into a ZIP file as many
> other apps do and this is quite doable but breaks older format version
> in a way.

Well, it’s a new format that old versions can’t read. But it doesn’t break
things as long as we continue to read the old format. And are able to
export the old format if the user requests it

> i suggested that we use byte chunks in XML e.g. embedding raw
> PNG/JPEG/format in a XML tag which is ugly but doesn't break the
> format.

No. NONONO. Nope. Nada. Nein. нет.

> tomaz suggested using marble to have photos on the map, in a way that
> i don't understand so i won't comment further on that, so please
> excuse me. :)

Which only adds another 400 MB to our executable size? I’d rather stay
FAR away from any more Marble dependencies.

> my point, i guess is that we need to get this thing in there eventually... :)
> in fact the sooner the better!
> 
> we need dirk and linus as maintainer decisions on this one!

Ha-hmm. I’m the maintainer. Linus is some random developer :-)

> i personally think that having the image files outside of the user
> file is out of the question as it will be very difficult to maintain a
> dive file copy/transfer as there will be multiple files…etc

Yes, I think they need to be linked.

> p.s.
> and if we plan wisely support for videos we are going to be quite much
> cooler, also ;)

Of course.

So we have talked about compressing the XML file before, and I’m not
opposed to that at all. What I am absolutely opposed to is embedding
the pictures in the XML file itself.

What seems logical to me is to add a couple of things to make this work
better and to help us in other places as well.

a) we need a unique dive ID. While we should consider using the fingerprint
that libdivecomputer provides (at least for the common case where the user
has just one DV), we need something else in case  we cannot compute that 
for dives that have been downloaded in the past (I haven’t looked at 
libdivecomputer source to see how it’s computed) or in cases where we have
multiple DCs (but maybe we can just use the fingerprint of the first one?).
Anyway, we need to find a way to create a reliable unique ID that doesn’t 
change when the user changes things like dive number, start time, etc.

This will make our lives much easier in other parts of the code where we can
simply hold on to that number and get rid of places where we hold on to pointers
or other numbers to identify dives.

b) we can then have a subdirectory with the hex encoded ID as name and
store all pictures that are associated with a dive in the subdirectory. And then
the marker in the XML file simply refers to the image name (and Subsurface
can lazily extract the matching image from the zip as the user asks to display
it

c) for easier passing around of data we should have to forms of exporting
(and saving) dives: 
(1) plain XML
(2) zip file which contains XML and subfolders with pictures and videos

I suggest .ssrf or .xml for the XML files and .ssrfz for the zip file

Does that meet your needs?

/D