Comments on latest changes

[Dirk Hohndel]

Linus Torvalds <torvalds at linux-foundation.org> writes:

> On Fri, Aug 17, 2012 at 10:55 PM, Miika Turkia <miika.turkia at gmail.com> wrote:
>> Generally I really like the new improvements. Seems to be working quite
>> well. However, I'd like to see some improvements as listed below:
>>
>> - Possibility to edit dive trip info - e.g. give a dive trip a more
>>   sensible name than the first dive's location
>> - Merging dives into a trip (and maybe even splitting a dive trip into
>>   pieces) - a few non-diving days in a trip might still warrant for a
>>   single dive trip instead of two
>
> I think the mistake we did was to call them "Trips".
>
> They really aren't. They are "Dive groupings" (think along the lines
> of "very approximate possible nitrogen loading groups"), but they are
> dive groupings where the header makes it hopefully very easy to then
> associate them with dive trips and dates.
>
> I don't think we should necessarily move subsurface to explicitly
> track trip information, although if somebody really wants to and
> writes the code, I guess I'm not going to complain violently. It's
> just not something I'd personally work on or worry about, and I really
> think that it might be better to just instead make it explicit that
> it's not so much about "Trips" (after all, the dives could all be
> local in your back yard pond) as it is about a simple date-based
> grouping/clustering to make it easier to see what's been going on.

I actually like this idea and want to tackle this next.

Let's talk about semantic and implementation for a moment.

This would mean that we are tracking trips in the XML format.

They could be tracked as dives that are special - and my gut feeling is
that Linus will immediately hate this. So let's walk through it, first,
before I write the code.

A dive today has about the following structure

<dive number='[positive int]' rating='[0-5]' date='[date]' time='[time]' duration='[duration]'>
  <depth max='[float] m' mean='[float] m' />
  <temperature water='[float] C' />
  <location>[text]</location>
  <divemaster>[text]</divemaster>
  <buddy>[text]</buddy>
  <notes>[text]</notes>
  <suit>[text]</suit>
  <cylinder [data] />
  <weightsystem [data] />
  <event [data] />
  <sample [data] />
</dive> 

We could modify this to add a 

  <divetrip number='[negative int]' />

tag to the dives and then have a dive with a negative number be
special. Something like

<dive number='[negative int]' count='[positive int]' date='[date]' >
  <location>[text]</location>
  <notes>[text]</notes>
</dive>

But we could also create a separate structure for trips

<trip number='[positive int]' count='[positive int]' date='[date]' >
  <location>[text]</location>
  <notes>[text]</notes>
</trip>

(and therefore use a positive <divetrip number='[positive int]' /> tag
in each dive to track those)

We would track them in memory in a separate list dive_trip_list. Which
includes the information above plus a linked list of dives that are in
that trip. The dive_list would include the divetrip index.

When importing dives from the computer we follow today's logic (date
based). But then a user is able to double click on a summary entry, edit
location and notes. And a user is able to add or delete divetrip
entries. And to edit the divetrip index that a dive belongs to.

The constraint that I would enforce is that dive trips need to be
sequential, i.e. you can't have a dive in the middle of a trip not be
part of a trip.

With this we could allow dives to not be part of a divetrip (i.e., be at
the top level in the divelist). That could be marked by a specific
<divetrip number='0' /> entry (with 0 not allowed as trip index). That
way we can tell apart dives that come from a different source and have
no trip identified and should therefore have a group created for them
based on date, and dives that we intentionally want at the top level.

Or we could nix that idea and say (just like today) "every dive has to
be in a trip, even if it is a trip with just one dive".

(if I wanted to go crazy we could make trips of trips and add another
level to the hierarchy (not seriously suggesting this - but if
implemented right this should be possible).)

Comments, suggestions?

/D