RE: Gateway / CAS include issue

["Jeff Hill" <johill@lanl.gov>]

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