Mapping country code to ISO3166

I just started adding a front end to NetTime to Alarm and thought it would be nice to autoselect a timeserver from one from the pool.ntp.org range.

One step up in finessing would be to choose a regional one, and the icing on the cake would be to select the country local one because network propagation delays are likely to be less and hence the time easier to sync.

To do that I need some mapping from the configured country to the 2 letter country code. So, “*CONFIGURE Country Switzerland” would allow me to find “ch” as the answer.

I had a quick look in Territory Manager and the International module but couldn’t see anything. Does this table already exist somewhere? Internet module maybe? Unicode resources? Font manager?

If it doesn’t exist, is the International module the right place to go?

I’ve never come across this, though I’m not very familiar with the Internet stack. I don’t think there’s anything like this in the Unicode resources. It’s not really relevant to Unicode, other than a vague international theme ;) I’d say the International module is the obvious choice, but I’m sure you’ve got a better handle than most on where it should go!

I just started adding a front end to NetTime to Alarm

Bummer. Ben and I were just talking about this and agreed that !Alarm is the wrong place for it – what RISC OS needs is a !Configure plug-in to do date, time, timezone, nettime, etc. Just like every other OS in the world. The problem with bolting this into !Alarm is that a) it’s not part of !Configure to confusingly different and b) lots of people don’t use alarm and use something else (e.g. Organizer).

I don’t suppose I could convince you to look at doing this as a plug-in rather than changes to !Alarm could I?

Bummer. Ben and I were just talking about this and agreed that !Alarm is the wrong place for it

Do you think this perhaps points to a bigger problem here, that maybe developers should be discussing the work that they would like to do before going ahead and doing it? The problem with things currently is developers can just pick a pet project, develop it and check in the code and it kind of forces RISC OS down their particular route rather than down a consensus route.

Do you think this perhaps points to a bigger problem here

That’s why this code review section of the forum exists. The idea is that people discuss their plans before work starts to that everyone gets a chance to stick their oar in.

I had a quick look in Territory Manager and the International module but couldn’t see anything.

Did you look at “Territory_Number” which returns the currently configured number, and “Territory_NumberToName” which converts that number to the name?

It returns UK here, but I’m not sure whether it always returns the 2 letter code or the full name for others.

It returns UK here, but I’m not sure whether it always returns the 2 letter code or the full name for others.

It’s just convenience that the UK also has a ‘.uk’ top level domain name, sadly it doesn’t work for other territories

It was s’posed to be .gb.

what RISC OS needs is a !Configure plug-in to do date, time, timezone, nettime, etc. Just like every other OS in the world

Including RISC OS Select! As Select is generally more advanced in terms of configuration options and user customisations, when adding such features to RO5 can I suggest the layout is copied from there? It will make life much easier for users and documentation writers.

can I suggest the layout is copied from there?

Have they given up their copyright or are you suggesting ROOL should license Select elements from ROL?

No, just suggesting things are kept as similar as possible – e.g. if the ROL configure plugin is called “Time & Date” then don’t call the RO5 version “Clock Setting” making it harder to find!

Of course what I would really like would be ROL to bundle up a lot of their additions and sell them as an add on pack for RO5, but that seems unlikely :-(

No, just suggesting things are kept as similar as possible

I seriously can’t see how that wouldn’t infringe their copyright. It’s not only the code base that’s protected but also functionality and GUI design. Looking back this seems to be asking for trouble.

Perhaps we need an expert in software copyrights. It appears that derivative works may extend to "general patterns of similarity" (if the work is “virtually identical” – Protecting a Company’s Graphical User Interface). However, imitating the layout wouldn’t of course be based on the source code… unless the changes were fed back and the forks effectively merged.

But naming things for what they do can’t be copyrighted! I’m not suggesting we steal the icon designs, they would need to fit in with the RO5 theme.

Besides, no one in the RISC OS world can afford the lawyers anyway.

Any-hoo, so sounds like the answer is this information isn’t in an existing API and the International module (Service_International) would seem a sensible place for it?

I just started adding a front end to NetTime to Alarm

Bummer. Ben and I were just talking about this and agreed that !Alarm is the wrong place for it

‘Just started’ was the key phrase there – no keyboard has been harmed yet, only brain cells, hence the ISO3166 question: design first, code later.

I don’t think I’ve even seen 2-digit country codes anywhere near the territory system (at least since before RO5), so I think you’re right. Service_International looks like a sensible place.

The country allocation is a bit of a mess – we have things like ‘Arabic’ or ‘LatinAm’ – how do you map those to country codes? Does it need a means to return more than one result (DNS lookup style)?

The country allocation is a bit of a mess – we have things like ‘Arabic’ or ‘LatinAm’ – how do you map those to country codes?

I don’t , since they’re not countries.
I acknowledge the country allocations are a bit odd (at present), but there are today 262 mappings in the ISO3166-1 already but only space to reserve 100 countries, and only 1 byte in CMOS to hold it. There was useful future guidance on the topic of unicode alphabets which suffer from the same lack-of-bits.

The API doesn’t preclude more than 100 countries in the future, so I’m safe to kick it into the long grass for now.