"Standard" properties; case-insensitive handling of property names

[kasemir]

The "standard" property names used by channel finder itself as well as the 'rec sync' package which is the de-facto standard for populating channel finder data uses a mix of upper/lower case:

• Name, Owner start with capital letter
• iocid, time and the suggested archive marker are all lower case
• hostName, iocName, pvStatus, recordType are wonky camelCase

The example recsync IOCs set environment variables LOCATION and ENGINEER, somewhat suggesting that they matter and end up in channel finder properties, which at this time they don't, but if they eventually will, would that be as LOCATION, Location, location, ...?

The "Channel Table" would look better with consistent casing, for example strict CamelCase:
Name, Owner, Hostname, IocName, IocId, PvStatus, RecordType, Time, Location, Engineer, ...

Simply changing the properties now would of course break existing installations because the search is case-sensitive. But then the case-sensitive nature of property names is actually another issue because users need to remember that searching by record type requires typing "recordType".
So at the same time of adjusting the PropertyNameCase we could make the search case-insensitive regarding property names, so any of "recordtype=ai", "recordType=ai", "RecordType=ai", "RECORDTYPE=ai" would give the same result.

[shroffk]

So,
The name and owner in ChannelFinder are all lower case (and since they are one word they also comply with the camel case format) and so the channel table should be updated to correctly

I have opened a PR with the above fix.
ControlSystemStudio/phoebus#2404

Also, I have added support to allow users to search for channels where the property and tag names are case insensitive.

so any of "recordtype=ai", "recordType=ai", "RecordType=ai", "RECORDTYPE=ai" would give the same result.
now works

#65

Note:
The channel names and property values are still case sensitive, this was a behaviour inherited from EPICS and we might have a hard time getting rid of it.
Also, while the search operations have a degree of case insensitivity, creating and deleting operations still respect the case... so I plan to keep this issue ticket open a bit more till we are able to agree on a more complete naming convention

[kasemir]

Very good progress!

For channel and property names, yes, EPICS channel names are certainly case-sensitive. The channel finder absolutely needs to preserve the case, otherwise a "caget" will fail.
Still, I'm pretty sure 99.89% of all users would find a case-insensitive search more convenient. You search for *sec*42*temp, find "Linac:Sector42:Temp", "RING:SECTION42:TEMP", ... and pick the one you wanted. You perform the search exactly because you don't know the PV name and can't remember if it was Temp or temp or TEMP.

[shroffk]

Ah!!!

Still, I'm pretty sure 99.89% of all users would find a case-insensitive search more convenient. You search for "sec42*temp", find "Linac:Sector42:Temp", "RING:SECTION42:TEMP"

I think I very much agree with this...I think we go ahead and make channel name and property value searches also case insensitive... but we preserve case in the name and property value so that usage in things like caget and other links to from the property value which are case sensitive continue to work

[tynanford]

Great work Kunal!!

And +1 on Kay's comment, I am in that 99.89% group too

[shroffk]

Done
d957eab

Adding some simple integration tests I don't believe this should have any major impact on any app/users