2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 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: Network Accessable Types |
From: | Ralph Lange <[email protected]> |
To: | EPICS Core Talk <[email protected]> |
Date: | Tue, 26 Jul 2005 16:51:11 +0200 |
Well, yes. Sure. But: wasn't that the point?!Maybe I'm misunderstanding the discussion, but for me the line of argumentation is as follows:
- There will be buffer boundary issues when transferring strings (or structs or arrays). If one of these things is larger than a buffer - for sure. Else - only now and then when filling these things into a network buffer hits the buffer end.
- The user interfaces (APIs) to those things should completely hide these issues.
- Therefore the implementations of these APIs must be able to cope with buffer boundary issues, i.e. they must be able to handle storage in non-contiguous blocks. The interface must allow for such implementations.
If we're trying to agree on one interface, that interface must allow non-contig.-storage implementations, else CA won't be able to use it.
If we're trying to agree on one implementation that is reusable all over the place, that implementation must be able to handle non-contiguous storage, else CA won't be able to use it.
It is desireable to separate the interface from the implementation, as this would allow other implementations (that might be smaller/simpler/faster by not supporting non-contig.-storage) to be used in adequate places while still keeping the same interface.
If we allow something in the interface that requires contiguous storage (such as c_str), we either restrict the implementation to contiguous storage (which won't work for network buffers) or force the implementation to double-buffer everything to have it in a contiguous place (which is bad in performance and memory fragmentation issues).
Or do I miss something important here?! Ralph Kay-Uwe Kasemir wrote:
On Jul 26, 2005, at 05:49, Ralph Lange wrote:1. Learning the native type of data is part of the DA interface. The DA interface is purely about data and does not have any notion of network transport. An application may access things within a library or through shared memory using DA without any network involved.I agree, and if you do, doesn't it follows that the application shouldn't have to deal with possible network buffer boundaries? The application should see a data interface that allows random access: List the properties, learn that the 5th property is the "value", typed as some sort of number, then fetch it as a double. Ask for the "units" property as a string, ... The V3 channel access library does hide the network delays and buffer boundaries from me, I eventually get the full DBR_CTRL_XXX and can access any piece in there in random order. (Yes, it requires pre-configuration of the max. array size) Why should the new data access interface involve the application in the handling of the incoming network stream byte-by-byte, maybe first receiving the time stamp, then a few initial characters of a string value, then the next 2 chars, ...? Thanks, -Kay
-- Ralph Lange [email protected] Tel: +49 30 6392-2117 BESSY Controls Group www.bessy.de Fax: ... -4859