<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Actually, the type/category stuff will be essential to make Subsurface aware when some specific field is required... eg. is it a camera? so, let's include a field to store the resolution (of course, it's just an example - I think that we should avoid having specific fields, since users could add extra info in a kind of 'comments' field - however, some equipment must have specific fields - like cylinder) ...</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div></blockquote><div><br></div><div>Yeah, avoid where possible. I don't think there's need for anything except some notes for *most* items.  It might be useful later down the line for reporting capabilities. "Show me all dives where I used my Buddy BCD" etc. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I got your point and I also would love to have more comments about it.</div><div>But as I mentioned above, it would not be hard to know that a specific equipment requires specific fields - so it would work fine anyway, in addition, it seems to be much more consistent (all equipment following the same structure).</div></div></div></div></blockquote><div><br></div><div>So perhaps we go along the line of including cylinders, see what the implementation looks like, and we could revert to the existing system if we need to. <br><br>Also think about migration of existing Cylinder/weights/suit data. </div></div></div>