On 2014-08-25 18:06, Dirk Hohndel wrote:
Humor aside, I continue to be puzzled by this argument. There are a couple of divecomputers that provide these data and there is a clear use case. Whether you use it on your dive computer frankly doesn't matter (and just for the record, I tend to always adjust the tank size on my Uemis). What matters is that there are data that could reasonably be provided by libdivecomputer at zero incremental cost for all the dive computers that don't have it, though for the past two years whenever the conversation comes up you explain why it's not needed.
I agree, gasoline cars work and most cars have a gasoline engine. There are only a few electric car makers out there. Yet as the owner of two such cars I think it would be useful if gas stations and hotels provided a way to charge cars. Oh, and they use different charging ports. One that's a bit awkward but very popular, the other that's better and used by the rest of the world. Smart gas stations and hotels will support both...
But I digress. It's your project. I continue to be too lazy to fork it so I will continue to just work around the parts where you don't see that you continue to go the wrong direction.
[Sorry for the slow response, but I've been busy with non libdivecomputer related things.]
I was only explaining the arguments why *I* think the tank size isn't a critical piece of information. Just like you explained yours. Nothing more, nothing less. With good arguments, you can certainly convince me to do things different. That's why I asked for feedback in the first place! Otherwise I would just have applied the change and be done with it.
Yes, you are absolutely right that I'm often reluctant when it comes to adding new features. However you have to keep in mind that I get many request for adding new features. Usually those are along the lines of "Hey, I have dive computer X and the official application shows info Y, and I would like to have that in application Z too". In theory (ignoring the time required to reverse engineer the necessary info), I can easily add support for such new features, because they don't really interfere with anything else. But the real question here is not whether we can support this, but whether we want to!
Remember that adding features ad-hoc, based on what a certain manufacturer (e.g. suunto, which happens to be the first supported devices) provides is pretty much how the current libdivecomputer "design" evolved into what we have now. Linus and you already complained several times about the current libdivecomputer api. Don't get me wrong, I absolutely agree that many of those concerns are indeed valid and should be addressed. But for the time being, I just don't want to repeat those mistakes again. So yes, I'm a lot more careful when it comes to adding new features now.
Also from an application point of view, I think it's more interesting to have a rather limited set of features that is very well supported by the majority of the backends, then having a large number of features that are only supported by a few backends. That's basically why I have been spending most of my time and energy on improving the existing features, and not adding anything new.
But okay, maybe I went into the defensive corner too fast. So let's start all over again, and assume we want to include the tank size too. Can you explain me how you would use the dc_tankdata_t structure in the following scenarios:
* No tank size available (e.g. just begin/end pressure): How do we indicate that the tank size isn't available?
* Metric vs imperial tanks (e.g. water vs air capacity): How do we indicate the difference? For imperial tanks, we'll certainly need the working pressure. Metric tank also have a working pressure, and although it's not needed for calculating the amount of gas, it may be available too. Do we convert imperial units to metric units to be consistent with the rest of the libdivecomputer api, or do we make an exception here?
And then we can work out something from there.
Jef