User:AndrewJohnson/Channels as URIs

ACTION ITEMS item #3482213: AI on AJ by Feb 14: Describe protocol distinction problem, his prefix namespace solution, and illustrate with his proposal for what "ezpva" get of 2 channels (one v3 and one v4) should look like.

The fundamental concept of a PV name is common to both Channel Access and PV Access, as are many of the operations that can be performed with one. However the two do not share a common namespace, in that names searched for using Channel Access will not be found if they only exist in PV Access, and vice versa. It is highly desirable to be able to create names that indicate which namespace they are found in, so that users don't have to use a completely different set of tools to work with Channel Access channels than with PV Access.

CSS already has a solution to this issue, it has (partially) adopted the standard approach and URI syntax developed by the internet community, Internet Standard STD 66 available at http://tools.ietf.org/html/std66 for the full details. The Wikipedia page http://en.wikipedia.org/wiki/URI_scheme is a much shorter read and gives a long list of other schemes already in use.

In CSS Channel Access PV names start with the prefix ca:// (the original epics:// prefix is apparently being phased out) and according to Gabriele Carcassi PV Access names will use the prefix pva://. CSS provides a configuration parameter that allow a default prefix to be chosen so that names can be given without specifying any prefix. CSS just passes everything after the prefix to Channel Access and doesn't try to enforce the formal URI syntax or handle character escapes; doing any more than CSS does would be admirable, but would complicate the code.

I suggest that PV Access tools should check PV names for a URI prefix and reject (or warn about) any names that start with a URI prefix that is not pva://. The prefix should be stripped before passing the rest of the name on to the PV Access layer.

Some tools could support ca:// prefixes as well as pva:// ones, using the libca routines to access those channels, although doing that is obviously going to complicate the code. It would be nice to have a library that handles both pva:// and ca:// names transparently and presents a common (presumably PVAccess) API for all channels even when using libca. Such a library should have a parameter (set by an environment variable for command-line tools) that specifies a default prefix to use for names that don't have one.

Here's how I would imagine using an EZPVA API to fetch three channels, one using Channel Access, one using PV Access and one using whatever is the current default protocol. Language is pythonic:

 channels = ["ca://S35DCCT:currentCC", "pva://S:ActualMode", "SRFB:GBL:Loop"]
 (current, mode, loop) = EZPVAGet(channels, timeout=5)