EPICS Home

Experimental Physics and Industrial Control System


 
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  <20192020  2021  2022  2023  2024  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  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Basic PVAccess question
From: "will.rogers--- via Tech-talk" <[email protected]>
To: Marty Kraimer <[email protected]>, Michael Davidsaver <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 5 Mar 2019 11:39:53 +0000
I could update exampleCPP to obey this convention.


Should I submit pull requests to Github? https://github.com/epics-base/exampleCPP


Some repos request that changes go to Launchpad.


Cheers,

Will


________________________________
From: [email protected] <[email protected]> on behalf of Michael Davidsaver via Tech-talk <[email protected]>
Sent: 04 March 2019 23:57:36
To: Marty Kraimer
Cc: [email protected]
Subject: Re: Basic PVAccess question

On 3/1/19 3:44 AM, Marty Kraimer wrote:
> Will and I had some private messages and now I think I can give an explanation of what we found.
> pvcall appears to assume that both the client and server use normative type nturi.

Correct.

I've seen four different developers find four different ways to encode RPC arguments.
Mutually incompatible of course.  Providing 'pvcall' is my attempt to encourage the
use of a single scheme, to facilitate interoperability.

> Now I have some questions about pvcall and channelRPC.
> Is pvcall meant to replace eget?

eget remains available for those who wish to use it.

https://github.com/epics-base/eget

> Are there plans for future enhancements to channelRPC?
> If yes then what is the status?

If you mean a change to force the use of NTURI?  No.
The foot gun will remain loaded.

-- 
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


Replies:
Re: Basic PVAccess question Marty Kraimer via Tech-talk
References:
Basic PVAccess question will.rogers--- via Tech-talk
Re: Basic PVAccess question Marty Kraimer via Tech-talk
Re: Basic PVAccess question Michael Davidsaver via Tech-talk

Navigate by Date:
Prev: Re: Basic PVAccess question Michael Davidsaver via Tech-talk
Next: Questions about channel access C API programming Abdalla Ahmad via Tech-talk
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  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Basic PVAccess question Michael Davidsaver via Tech-talk
Next: Re: Basic PVAccess question Marty Kraimer via Tech-talk
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  <20192020  2021  2022  2023  2024