2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: V4 Data Types: Request for tagged unions |
From: | Ralph Lange <[email protected]> |
To: | [email protected] |
Cc: | EPICS Core Talk <[email protected]> |
Date: | Thu, 16 Jun 2005 15:26:27 +0200 |
Benjamin Franksen wrote:
Hm. I don't see any problem with my original idea to have the write traversal for a tagged union (exactly like the read traversal) first provide the tag and then only the properties that are valid for the new tag value. Valid write operations would succeed, invalid operations would fail, no meaningless properties being provided in the process.On Thursday 16 June 2005 12:55, Benjamin Franksen wrote:On Wednesday 15 June 2005 23:12, Andrew Johnson wrote:To step back a little: I don't understand why your states have parameters, and what you could do with them - presumably I can't put a CA monitor on a member of a tagged union (what happens to the monitor when the state changes and the member no longer exists?).It must disconnect, indicating that the value in question no longer exists. Note that a similar question must be answered for the case of adding/removing views. Here, too, the client will need to receive notification that a certain value is no longer available. We could make this a dedicated event type so that clients can react in a generic way to such conditions.Let me state this more precisely:The very idea of a tagged union implies that independent read or write access to properties subordinate to a certain tag hardly makes sense. I cannot change, nor query, the scanRate of a record, as long as I am not certain that the tag is 'Periodic'. However, subscribing to merely a certain subordinate property might reduce system load.The problem is that changing the tag independently brings the other subordinate properties to an undefined state and this is something we can't handle because we don't have a representation for "no value here". Thus, at least write access must provide all values every time (i.e. tag + add. properties), while reading and subscribing to either tag only or other properties can be allowed but must fail in case of unavailability.
Ralph