DiveLab [was Re: Subject: Re: struct dive_table dive_table and a wider view]

Alex Deas alex at deeplife.co.uk
Thu Apr 18 09:43:34 PDT 2013


Dear Dirk,

Apologies on reply, protocol is noted. Thanks, and for your feedback.

We don't see why UDDF should be "a sad story" as you suggest.  We are quite
happy to put in the work to add the items suggested to the parser, in the manner
suggested (which is open to discussion and amendment on a consensus basis).  The
proposal was simply to add in elements or extend elements to enable UDDF to
support rebreathers and make it more efficient, for some future release once
everyone has checked there are no side effects or negatives from those
additions.

We note your comments on not moving to SQL.  Again, it was  a free offer to
provide an SQL-Lite interface from our side, and one that could have happily
co-existed with the current bespoke data structures.   We note you don't wish to
go down the road of us doing work to integrate to Subsurface to support large
dive database using SQL, so we would need to create a derivative work if were to
move towards Subsurface.  Thanks for reminding us of the licence, and that fits
well with our objective of an open tool and would of course be respected.

On PDF, the doc was on a server, not linked in to anything other than in my
email, and was there to provide a point to solicit the feedback - I am sure
people would not want unsolicited PDFs arriving, but a link means they can look
at if if they are interested, and ignore it if not.  We tend to work with open
and frank review of docs to agree specs before starting work, and given the
discussion nature of it, is not something we thought would be unwelcome as
repository submission in the first instance.

We are not new to Subsurface type tools, and there are the two issues; a format
for getting the dive log data from the products, and storing it in a file,
hopefully with fewer converters, then the tool for reading it.   You have done a
very good job with Subsurface, and for sports dive computers it seems a good
solution.   Our comments on UDDF efficiency seem to be accepted we were looking
at what could be done in a backwards compatible manner to resolve its problems,
and separately, to solve the problem of when one tries to get Subsurface to read
a big dive log from a rebreather.   From your email, there seems to be no
interest in us contributing effort from staff to deal with these two
shortcomings, so we will keep watching from the sidelines.

I will continue to get the doc on DiveLab released as it may be useful to others
considering some of the issues of working with rebreather data in dive logging
tools. It at least does not mention Subsurface, as it predates it, so hopefully
ruffles no more feathers.

With kind regards,

Alex



On 18 April 2013 at 15:57 Dirk Hohndel <dirk at hohndel.org> wrote:
>
> On Apr 18, 2013, at 3:26 AM, Alex Deas wrote:
> > Caveats: We have not been involved in Open Source previously,
>
> That appears rather obvious. I would suggest that you read
> up a little on mailing list behavior, for example. Top posting
> and quoting a complete 7 email digest, retaining the old
> subject line but changing the topic is a great way to get
> people really mad at you, really fast.
>
> Coming in showing blatant lack of understanding for what
> we do and how we do it and who we do it for is another.
>
> > So any comments on what we are proposing to do with the UDDF parser to start
> > with, and then SQL-Lite, would be most welcome so we can get the objectives
> > and spec clear, than we are happy the work is defined, we can contribute a
> > person or two do those things.
> >
>
> UDDF is a sad side story for us. It's an over engineered
> ridiculous abomination and not something we are interested
> in spending time on. We have some limited support for it out
> of concern for interoperability but that's about it.
>
> Moving to an SQL style database will not happen. End of
> story.
>
> And reading and commenting on a PDF that someone I have
> never heard of before posts on some server that contains a
> discussion of a data format I have no interest in. Please hold
> your breath while I am doing that and until I respond. Please
> do. Really
>
> Feel free to fork Subsurface. But please pay close attention
> to the license under which it is released and the requirements
> that this license puts on any derived work.
>
> Good luck
>
> /D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130418/280e37be/attachment-0001.html>


More information about the subsurface mailing list