Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: Gateway / CAS include issue
From: Michael Davidsaver <mdavidsaver@bnl.gov>
To: "'Ralph Lange'" <Ralph.Lange@gmx.de>
Cc: "'EPICS Core Talk'" <core-talk@aps.anl.gov>
Date: Mon, 09 May 2011 11:43:24 -0400
Ralph,

If Jeff implements this solution, how difficult is the change to the gateway? If it is worth it, a short(er) term solution is adding another binary package (ie epics-pcas-dev) with the necessary headers. I'm working on another revision of the epics packaging this week anyway.

Michael


On 5/6/2011 4:42 PM, Jeff Hill wrote:
Hi Ralph,

I think that Ken Evans started the practice of making the gateway dependent
on the private pcas headers. The casCtx.h and caHdrLargeArray.h are
certainly private parts of the pcas design, were never intended to be part
of its public interface, and from my perspective exporting them does raise
some concerns about maintaining a proper level of independence between
server internals and the service code.

because it needs to know which event
mask the exterior client used in a subscription.
I am happy to place a property in the gdd passed to "gateVcData::read(const
casCtx&  ctx, gdd&  dd)" which specifies the event mask. This property would
be present only if the read request was occurring because the server library
is obtaining the first subscription update. It would perhaps have the name
"subscriptionEventMask". Presumably the gateway would probe the incoming gdd
for this property. If present, it would update the GW PV's maximized
knowledge of the client channel's subscription event mask(s) (there could be
more than one subscription per channel), and otherwise not. So, under that
scenario, sites needing the event mask awareness functionality would need
also a contemporary version of PCAS that implements "subscriptionEventMask".

So, after admittedly a very short time considering the issue, the above
option appears from my perspective to be an approach which eliminates the
negative aspects of exporting private header files while also providing the
required functionality. Let me know if you like this option, and I will be
happy to implement the small amount of code required ASAP in order to
minimize inconvenience getting a proper packaging together for the GW. This
type of change is probably appropriate for an R3.14 patch release, and also
a patch file (maybe satisfying demand until a patch release is available).

The PCAS API is admittedly a bit broken wrt to this issue. The new server
does in fact invoke a special method in the service to start a subscription
which allows for conveying the necessary subscription context using a more
obvious and direct mechanism. In theory it's possible to make a PCAS service
compatibility layer that wraps the new server's service interface, thereby
minimizing the size of the ca code base during the transition, so the issue
of maintaining a clean interface might be a genuine one.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925


-----Original Message-----
From: core-talk-bounces@aps.anl.gov [mailto:core-talk-bounces@aps.anl.gov]
On Behalf Of Ralph Lange
Sent: Friday, May 06, 2011 2:56 AM
To: EPICS Core Talk
Subject: Gateway / CAS include issue

Hi.

Preparing to package the CA Gateway I find the Gateway needs casCtx.h
(which in turn pulls in caHdrLargeArray.h), because it needs to know which
event
mask the exterior client used in a subscription.

casCtx.h and caHdrLargeArray.h are not installed as include files by CAS.

To make compilation work, the Gateway Makefile adds BASE/src/cas/generic
to the include path.
Of course, this does not work nicely with binary packages, where the "...-
dev" development package, which is a build dependency of the Gateway
package, contains (installed) include files and libraries, but no sources.

What are the different stakeholders' opinions?

Is casCtx.h a public interface of CAS?
The Gateway is an important client app and undoubtedly needs it: Should it
be made public? Or should the functionality rather be included in one of
the existing public interfaces?
Should - as a workaround to allow packaging the Gateway- the epics-dev
package just install the two header files?

Thanks,
~Ralph



References:
Gateway / CAS include issue Ralph Lange
RE: Gateway / CAS include issue Jeff Hill

Navigate by Date:
Prev: RE: Gateway / CAS include issue Jeff Hill
Next: 64 bit integers (aka. long or long long) Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: Gateway / CAS include issue Jeff Hill
Next: 64 bit integers (aka. long or long long) Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·