Handling PV-Name prefixes for archive data sources

[MichaelRitzert]

I recently switched from the RDB archiver to the archiver appliance, and I find that my databrowser plots are no longer working. The obvious reason is that in the old setup, I had the PVs stored as "ca://name", while the appliance only likes "name". After the switch, this means that I cannot have a plot that can read data from both sources transparently.

I don't really like the situation with the appliance, because our OPIs pass around macros containing the common "ca://${USER}:etc" part of PV names, so I cannot easily create a parametrized plt file – the ca:// would always be there. Just omitting the prefix from the OPIs and relying on the default (or using ca://${name} in every widget) doesn't look to attractive to me.

But also for the RDB archiver, it can be confusing for the users to not find a PV because they forgot the ca://.

Would it be possible to extend the logic of the archive reader(s) to retry without the PV name prefix if a channel is not found?

[kasemir]

At earlier times I would have suggested that you drop the ca:// (or epics://) prefix, but there are EPICS sites which start to use both Channel Access and PV Access, so their displays as well as archive configurations will require some prefixes.
For example, the default may be ca:// but some PVs now use pva://. Or you switch the default to pva://, and use ca:// for older channels.
Or you don’t depend on any default and always specify ca:// resp. pva://

In any case, I think this is best handled by the archiver appliance. Its data server needs to allow prefixes.

I recently switched from the RDB archiver to the archiver appliance, and I find that my databrowser plots are no longer working. The obvious reason is that in the old setup, I had the PVs stored as "ca://name", while the appliance only likes "name". After the switch, this means that I cannot have a plot that can read data from both sources transparently.

I don't really like the situation with the appliance, because our OPIs pass around macros containing the common "ca://${USER}:etc" part of PV names, so I cannot easily create a parametrized plt file – the ca:// would always be there. Just omitting the prefix from the OPIs and relying on the default (or using ca://${name} in every widget) doesn't look to attractive to me.

But also for the RDB archiver, it can be confusing for the users to not find a PV because they forgot the ca://.

Would it be possible to extend the logic of the archive reader(s) to retry without the PV name prefix if a channel is not found?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1655.

[jbobnar]

In any case, I think this is best handled by the archiver appliance. Its data server needs to allow prefixes.

I think the prefix does not belong to the server. The prefix is a CSS feature to distinguish the protocols. In general archive server doesn't know about those protocols. It only knows the PV names and doesn't care if the client has different mechanism to retrieve the live data.

RDB archiver can digest that, because it is using the same plugins as CSS clients, and this results in the same behaviour.

The above pull request strips the schema prefix from the name before passing it to the appliance.

[kasemir]

I think the archive system (engine, data server) do need to understand the prefixes.

As we start to adopt EPICS V4, you can have both ca://fred and pva://fred on the network. Our archive engines understand the difference, CSS understands the difference, why should the data retrieval layer not see the prefix?

[berryma4]

How is Murali telling the protocol difference?
(Since he has started to support both ca and pva)

We might not be able to rely on a server to have the same uri format.
... so we might need to wrap.

On Thu, Mar 17, 2016 at 8:53 AM, kasemir notifications@github.com wrote:

I think the archive system (engine, data server) do need to understand the
prefixes.

As we start to adopt EPICS V4, you can have both ca://fred and pva://fred
on the network. Our archive engines understand the difference, CSS
understands the difference, why should the data retrieval layer not see the
prefix?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1655 (comment)

[jbobnar]

How is Murali telling the protocol difference?

It happens here

You can add the pv to the appliance as pva://foobar. If appliance sees pva://, it marks the PV as pvaccess type, strips the name of the prefix and uses only foobar for all further actions. When you ask for the data you do not need to specify the pv name as "pva://foobar", but you provide only "foobar".