EPICS Re: proposed RTYP field

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

Subject:	Re: proposed RTYP field
From:	[email protected] (Pete Jemian)
To:	[email protected]
Cc:	[email protected]
Date:	Thu, 8 Jan 98 15:11:11 CST

Regarding the proposed RTYP field for dbCommon:

Marty Kraimer wrote:
> With regards to accessing the record type via channel access, Matthais
> Clausen asked for this a long time ago. I have it on my 3.13 TODO list. 

In fact, I believe I first proposed this (November 1996).

A lengthy discussion ensued which branched in many directions.
It was not clear from the discussion what path would be taken.
It appeared to me that the purpose of this field was lost during
the discussion.  That purpose was to allow a Channel Access
client to determine the type of a given PV.

> 
> Your proposal is one way to handle the problem (yet another dbCommon
> field???). It does, however, require that the client take a channel
> name, strip off the field, append "RTYP", and do a search and get. Maybe
> this is an OK interim solution. Another possibility is too see if some
> changes to dbAccess and ca can make it possible to just ask CA directly
> for the record type just like you can now ask for native type, native
> count, etc.

How is this simpler for the end user?  Seems like this makes more
work.  Better to provide a record field, then end users can access the
.RTYP field through a caget call.

> 
> Ultimately we should allow full dynamic discovery of record type, field
> names, field types. This will NOT happen until at least CA V4.
> 
> By the way this is the next item on my epics 3.13 TODO list. Thus
> comments are welcome. Maybe William's suggestion is what we should do
> for 3.13. It is certainly simple. The static database access library
> could fill in the name. Thus no other code needs to be modified.

Excellent approach.  One vote for ASAP.

Pete Jemian

Navigate by Date:: Prev: Re: EPICS r3.13 field DESC length William Lupton; Next: Re: EPICS r3.13 field DESC length Tim Mooney; 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: EPICS r3.13 field DESC length Jeff Hill; Next: RE: proposed RTYP field Jeff Hill; 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