The openSocket method should be deprecated, it is really not needed and should be removed in a future release. I actually thought we had already done that.
Mark
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Sinisa Veseli
Sent: Wednesday, March 20, 2013 1:54 PM
To: [email protected]
Subject: Re: drvAsynIPPort question
Hi,
I would also agree that existing interfaces could be enhanced to
simplify/clarify usage, without modifying what is already there. For
example, in asynOctetSyncIO.h I see the following methods:
/*asynOctetSyncIO methods*/
static asynStatus connect(const char *port, int addr,
asynUser **ppasynUser, const char *drvInfo);
static asynStatus disconnect(asynUser *pasynUser);
static asynStatus openSocket(const char *server, int port,
char **portName);
In particular, there is no "closeSocket()" method that I would expect to
see (and that would match the "openSocket()" method). Similar statement
can be made for various "configureIPXXX" methods.
Another possibility would be to introduce completely new package derived
from existing asyn, that would not have to be backwards compatible.
Regards,
Sinisa
On 03/20/2013 01:39 PM, J. Lewis Muir wrote:
> On 3/20/13 12:43 PM, Mark Rivers wrote:
>> Unfortunately we need to live with these names, it's too late to change them now.
> Hi, Mark.
>
> Thanks for your explanation. That is really confusing.
>
> I agree that it's too late to change the names, but have you considered
> adding new names? That way, things could be more clear for new
> development that doesn't need to be backward compatible. It could also
> make the documentation clearer since, for old names that are poor, you
> could refer to the new names they map to.
>
> To make new names, you could append the digit '2' to the names:
> connect2, disconnect2, connectDevice2, etc. Or you could add the words
> 'to' or 'from' to the names: connectTo, disconnectFrom, connectToDevice,
> etc. Or you could change the vocabulary to words like "bind", "attach",
> etc. Or there are probably other good schemes.
>
> Lewis
--
Sinisa Veseli
Software Services Group
APS Engineering Support Division
Argonne National Laboratory
[email protected]
(630)252-9182
- References:
- drvAsynIPPort question Sinisa Veseli
- RE: drvAsynIPPort question Mark Rivers
- Re: drvAsynIPPort question J. Lewis Muir
- Re: drvAsynIPPort question Sinisa Veseli
- Navigate by Date:
- Prev:
Re: drvAsynIPPort question Sinisa Veseli
- Next:
using debian package for camac? Michael Davidsaver
- 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: drvAsynIPPort question Sinisa Veseli
- Next:
delay before alarm on alarm handler James F Ross
- 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
|