Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reverse mapping: identifiers to device name #35

Open
petarov opened this issue Sep 28, 2023 · 3 comments
Open

Reverse mapping: identifiers to device name #35

petarov opened this issue Sep 28, 2023 · 3 comments

Comments

@petarov
Copy link

petarov commented Sep 28, 2023

First, great job with this repo. 👏 I was wondering what was the reason to map device names to identifiers and not the other way around?

Does it not make more sense to reverse the mapping and map the identifier (Product Name according to Apple) to the device name instead, e.g. "MacBookAir8,1" : "MacBook Air (Retina, 13-inch, 2018)"?

Device management solutions, for example, would often lookup the device name given its product name identifier and not the other way around.

@clo4
Copy link
Owner

clo4 commented Sep 29, 2023

I was wondering what was the reason to map device names to identifiers and not the other way around?

I'm so glad literally any other human on the planet cares enough about this to even ask 😄

The short reason, device identifiers aren't actually 1:1 with product names, sometimes they're shared between multiple products or generations. But product names are always unique -- if they're shared between generations, Apple distinguishes them by year.

"iMac (24-inch, Early 2009)": "iMac9,1",
"iMac (20-inch, Early 2009)": "iMac9,1",
"iMac (27-inch, Late 2009)": "iMac10,1",
"iMac (21.5-inch, Late 2009)": "iMac10,1",

Choosing to key by the product name was to make the mapping homogeneous and simple. It's always Record<string, string> instead of Record<string, string[]> or Record<string, (string | string[])>.

For this use case I created ids.json which has the inverse mapping of key:product. But for the sake of editing the files, that's why the devices directory is how it is. Much easier :)

"iMac9,1": ["iMac (24-inch, Early 2009)", "iMac (20-inch, Early 2009)"],
"iMac10,1": ["iMac (27-inch, Late 2009)", "iMac (21.5-inch, Late 2009)"],


(aside: there's been a weird increase in activity on my repos lately, makes me wonder if GitHub has changed a discovery algorithm eg. search or recommendations - curious how you found this?)

@clo4
Copy link
Owner

clo4 commented Sep 29, 2023

In thinking about this, I've decided that I'll move the definitions to a more human writable format (not yaml but will be the same for syntax highlighting) and process them into individual key:product and product:key JSON files, as well as the top level devices.json and ids.json files. That way we can have the best of all worlds!

{
"Apple TV (1st generation)": "AppleTV1,1",
"Apple TV (2nd generation)": "AppleTV2,1",
"Apple TV (3rd generation, Early 2012)": "AppleTV3,1",

... will become

Apple TV (1st generation): AppleTV1,1
Apple TV (2nd generation): AppleTV2,1
Apple TV (3rd generation, Early 2012): AppleTV3,1

@petarov
Copy link
Author

petarov commented Sep 29, 2023

The short reason, device identifiers aren't actually 1:1 with product names, sometimes they're shared between multiple products or generations.

Ouch! Didn't expect that. I wonder if this appears to be so for iOS/iPadOS devices. 🤔
(EDIT: Oh yeah, just found some like iPad6,12, iPad13,17....)

I actually have a use-case behind this being in the mobile device management (MDM) business. I have a CSV file with product mappings at the moment, rarely updated and I was looking for something I could tap into for regular updates. So that's more or less where my question stems from. 😉

not yaml but will be the same for syntax highlighting

Do you mean some custom format or something else?

But that'd be really great. Not sure if I can ditch the CSV format on my side, so maybe I'll transform the key:product JSON into a CSV. As for the multiple product names, I'll probably just use the last one in the list as a workaround. Just sharing my thoughts.

curious how you found this?

I actually have it on my watch list for months now. Probably discovered through Github's recommendations, I can't really remember.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants