support for images per dive

[Lubomir I. Ivanov]

On 5 January 2014 02:41, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> 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. нет.
>

haha :D
the sad part is that i see people do it in commercial projects.

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

erm, i'm confused is this following the
'ziping-dives-et-photos-in-a-single-file' logic?
why is there a need for a sub-dir, since we can directly, always store
in a zip on save?

perhaps i don't understand..

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

the two forms make sense and are quite doable for backward
compatibility, i just go confused about the upper part. :\

lubomir
--