Privacy and Security Notice

Archived Messages for CDEV@cebaf.gov: Re: Opportunities encountered when using Cdev

Re: Opportunities encountered when using Cdev

Chip WATSON (Chip.WATSON@cern.ch)
Mon, 04 May 1998 17:21:52 +0200

Steve,

>1. The return values of some methods (e.g. cdevRequestObject::attachPtr),
>have changed from cdev versions 1.6 to 1.6.2, in that they no longer return
>null pointers on failure.

>I would like to propose that the old behavior be reinstated, and that
>changes in the CDEV API be fully documented.

I would support both the restoration of returning null, and that no such
changes are made in the future without a request for comment and/or
release notes making the changes clear.

>2. The Cdev Java interface does not seem to be
>working with the new version of CDEV we have.

Regretfully, another case of changing something improperly. The
CLIP protocol was modified in 1.6.2 in a backwardly incompatible
way (i.e. 1.6 cannot communicate with 1.6.2 and the reverse). I don't
propose to undo this (it could have been done in a compatible way,
but the damage is done, and we are already operating with it).

A modified java cdev package will be posted to the ftp site ASAP
(this week). It successfully works with the 1.6.2 CLIP software
such as the cdev gateway as far as I know (I have used it a little).

>3. It is not clear how to cleanly disable the 'default' behavior
>of falling through to channel access. We want to use the caService,
>but only if the channel is defined in the .ddl file.

See the 1.6.2 release notes. This is now possible. (See extract
below)

>4. I would like to propose (as has been discussed) that it
>be possible to write a set of different values to a collection - rather than
>the present behavior which is all devices in the collection get the
>same (first) value sent.

I also support this proposal. Comments, anyone?

Chip

________________________________________________________

Extract from release notes:

6) In the previous versions of cdev, a default service (ca) is
used when a device and message pair does not match any service
from ddl files. This behavior can be turned off by
using a new cdevSystem member function. The following is a
simple example:

cdevSystem& system = cdevSystem::defaultSystem ();

system.disableDefaultSvc (); // fall through service
// is turned off

......

system.enableDefaultSvc (); // fall through service is back on