Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Mon, 9 Apr 2018 21:03:54 -0700

I'll mention for general interest that another relevant example of solving
this problem is the DBUS system.  A DBUS service has one well known method
"Introspect()" which returns a string (XML) describing all other methods.

https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format

I'm not advocating adopting this wholesale (and certainly no XML!) but
it is a working example with wide usage in the Linux world.

At some point I'd like to add a scheme like this to the P4P RPC server
helper API, which has access to the information needed to handle this
automatically.

https://mdavidsaver.github.io/p4p/rpc.html

On 04/09/2018 02:17 PM, Andrew Johnson wrote:
> Hi Renato,
> 
> Since EPICS hasn't had native RPC functionality at all before it was
> added in pvAccess, we don't claim to know what the best way might be to
> implement the introspection of RPC interfaces. We could have created a
> standard while writing pvAccess, but we have found in the past that if
> you try to make something generic before you have at least two and
> preferably three or more different examples you often don't make the
> result flexible enough to meet later needs.
> 
> I hope Diamond's "experiment" as Tom called it will help the community
> eventually come up with an "official" approach, assuming of course that
> there is enough demand for a standard that someone is willing to fund
> the development work with either effort or money. If you have specific
> requirements we would be interested in hearing about them.
> 
> Regards,
> 
> - Andrew
> 
> 
> On 04/09/2018 02:13 AM, [email protected] wrote:
>> Hi Renato,
>>
>> That is correct, I would class this as "experiments in how you might do this" rather than "the official way to do this".
>>
>> Thanks,
>> Tom
>>
>>> -----Original Message-----
>>> From: renato sanhueza <[email protected]>
>>> Sent: 08 April 2018 04:47
>>> To: Cobb, Tom (DLSLtd,RAL,TEC) <[email protected]>
>>> Cc: [email protected]
>>> Subject: Re: question about pvAccess monitor
>>>
>>> Hi Tom,
>>>
>>>
>>> Your implementation of dynamic RPC using EPICS is very impressive.
>>> Nonetheless, if I understand correctly, it is not part of the "official" version of
>>> EPICS which I am studying right now.
>>>
>>>
>>> Thanks for sharing this information,
>>>
>>> Renato
>>>
>>>
>>> On Thu, Apr 5, 2018 at 9:45 AM, [email protected]
>>> <mailto:[email protected]>  <[email protected]
>>> <mailto:[email protected]> > wrote:
>>>
>>>
>>> 	>       2. Can I use this introspection interface to retrieve the name of a
>>> 	> service and its parameter list to compose a RPC during runtime by
>>> following
>>> 	> Marty's approach?
>>> 	>
>>> 	> I suspect that the answer for pvAccess itself is no.
>>> 	>
>>> 	> But even if the answer is no a channelRPC service can implement
>>> it's own
>>> 	> query service that describes itself.
>>> 	> But it must describe itself via pvData.
>>>
>>> 	That is the approach that Diamond has taken in its continuous
>>> scanning middleware:
>>>
>>> 	http://pymalcolm.readthedocs.io/en/latest/reference/structure.ht
>>> ml <http://pymalcolm.readthedocs.io/en/latest/reference/structure.html>
>>>
>>> 	We define a Block to be a container for a number of Methods and
>>> Attributes. Attributes are represented by NTScalars, NTScalarArrays and
>>> NTTables, but with their metadata abstracted to separate Meta objects.
>>> These same Meta objects are used to describe the arguments that a Method
>>> should be passed when doing an RPC on it, and the structure it will return.
>>> We implement this in Python, exposing the structures either over pvAccess
>>> (currently with a Diamond specific fork of an old version of pvaPy, but we are
>>> working on this) or as JSON over websockets.
>>>
>>> 	Thanks,
>>> 	Tom
>>>
>>>
>>> 	--
>>> 	This e-mail and any attachments may contain confidential, copyright
>>> and or privileged material, and are for the use of the intended addressee
>>> only. If you are not the intended addressee or an authorised recipient of the
>>> addressee please notify us of receipt by returning the e-mail and do not use,
>>> copy, retain, distribute or disclose the information in or attached to the e-
>>> mail.
>>> 	Any opinions expressed within this e-mail are those of the individual
>>> and not necessarily of Diamond Light Source Ltd.
>>> 	Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>>> attachments are free from viruses and we cannot accept liability for any
>>> damage which you may sustain as a result of software viruses which may be
>>> transmitted in or with the message.
>>> 	Diamond Light Source Limited (company no. 4375679). Registered in
>>> England and Wales with its registered office at Diamond House, Harwell
>>> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United
>>> Kingdom
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Renato Sanhueza Ulsen
>>> Ing Civil Informática.
>>
>>
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System