[chirp_devel] When to include an alias?
How comprehensive do we want to be with alias models? Leixen sold the same exact radio (from everything I can see in the images they are a binary match) as both the VV-898S and VV-898E. Should I bother making an alias model for the 898E, or do we just markup the web page to note that we support the model and it matches the S? Aliases make a lot of sense when the vendor name or model are grossly different, but I'm not sure it's worth doing in this case.
-- Brian
How comprehensive do we want to be with alias models? Leixen sold the same exact radio (from everything I can see in the images they are a binary match) as both the VV-898S and VV-898E. Should I bother making an alias model for the 898E, or do we just markup the web page to note that we support the model and it matches the S? Aliases make a lot of sense when the vendor name or model are grossly different, but I'm not sure it's worth doing in this case.
I think the most important use for an alias is when the things are so different that someone wouldn't think to use the right driver. Like, if two manufacturers release the same radio under different names -- that's a good reason. Just the trailing character is probably not a good reason. I'd even say just drop the trailing character from the driver itself to reduce confusion (i.e. name it VV-898, not VV-898S).
--Dan
I'd even say just drop the trailing character from the driver itself to reduce confusion (i.e. name it VV-898, not VV-898S).
I think dropping the letter completely will probably cause more confusion in this case. VV898 is the two power levels 10W version. Both VV898S and E are tri-power, 25W.
I think dropping the letter completely will probably cause more confusion in this case. VV898 is the two power levels 10W version. Both VV898S and E are tri-power, 25W.
Okay, so is there something in the image that tells you which model it is? If the _behavior_ is different then it shouldn't be an alias, it should be a separate subclass so it can expose the different power levels, etc.
--Dan
The driver can tell apart images from 898 and 898S and those have separate classes to handle the power states, but it can't tell apart E and S. Behavior of E and S are identical, so that's where we could use an alias.
On Sun, Sep 4, 2016 at 10:04 AM, Brian Dickman via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
The driver can tell apart images from 898 and 898S and those have separate classes to handle the power states, but it can't tell apart E and S. Behavior of E and S are identical, so that's where we could use an alias.
This is confusing. Sounds like a good use for an alias!
Tom
The driver can tell apart images from 898 and 898S and those have separate classes to handle the power states, but it can't tell apart E and S. Behavior of E and S are identical, so that's where we could use an alias.
This is confusing. Sounds like a good use for an alias!
Yeah, I didn't realize there was already a non-E-non-S variant, so alias sounds good for the E/S confusion.
--Dan
On Sun, Sep 4, 2016 at 1:04 PM, Brian Dickman via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
The driver can tell apart images from 898 and 898S and those have separate classes to handle the power states, but it can't tell apart E and S. Behavior of E and S are identical, so that's where we could use an alias.
I just did a driver for the LUITON LT-725uv. There is nothing in the downloaded memory that I could see that would be useful uniquely identify this image.
What I did, which was suggested to me by others, in order to be able to positively identify an image from this radio was to append the radio's model, LT-725UV, to the end of the downloaded data. This added identifier is outside of the "range" used for cloning to the radio, so it is invisible to the radio.
Jim KC9HI
participants (5)
-
Brian Dickman -
Brian Dickman -
Dan Smith -
Jim Unroe -
Tom Hayward