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.
>>
>>
>
- References:
- question about pvAccess monitor renato sanhueza
- Re: question about pvAccess monitor Johnson, Andrew N.
- Re: question about pvAccess monitor Mark Rivers
- Re: question about pvAccess monitor Johnson, Andrew N.
- Re: question about pvAccess monitor renato sanhueza
- Re: question about pvAccess monitor Marty Kraimer
- Re: question about pvAccess monitor renato sanhueza
- Re: question about pvAccess monitor Hartman, Steven M.
- Re: question about pvAccess monitor Kasemir, Kay
- Re: question about pvAccess monitor renato sanhueza
- Re: question about pvAccess monitor Marty Kraimer
- RE: question about pvAccess monitor [email protected]
- Re: question about pvAccess monitor renato sanhueza
- RE: question about pvAccess monitor [email protected]
- Re: question about pvAccess monitor Andrew Johnson
- Navigate by Date:
- Prev:
Re: question about pvAccess monitor Andrew Johnson
- Next:
Re: GpibBoardDriverConfig not found Vishnu Patel
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: question about pvAccess monitor Andrew Johnson
- Next:
Simple channel access write program within Qt Abdalla Ahmad
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|