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.

RESPONSE:

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 belong to and tools that handle them appropriately, so 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 -- see 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 list of URIs already in use.

In CSS Channel Access PV names start with the prefix ca:// (the original epics:// prefix is apparently being phased out) and PV Access names will use the prefix pva:// (from Gabriele Carcassi). CSS provides a configuration parameter that allows a default prefix to be chosen so that names given without specifying any prefix will use the default access methods. 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 and is not really necessary.

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-syntax prefix that is not pva://. The prefix should be stripped before passing the rest of the name on to the PV Access layer.

More advanced tools should 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 independent of protocol. Such a library should have a parameter (set by an environment variable for command-line use?) that specifies a default scheme to use for names that don't start with a URI prefix.

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. The language I'm using is meant to be vaguely pythonic but I don't want to be specific about it:

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