On Jun 20, 2005, at 12:10 AM, Thorsten Schuett wrote:
2) At GGF it would be worthwhile to walk through some existing consistency models and find out how they map into the API (are there error states or features that are not accomodated?)
3) Felix is correct that such a model potentially exposes the programmer to the worst-case scenario in terms of consistency models. This is one of the risks involved in anything that carries the moniker "simple". I see the point that it is hard guarantee a specific consistency model in SAGA or make it a configuration option to choose one. But if you completely ignore
On Saturday 18 June 2005 17:21, John Shalf wrote: this topic in the specs you will end up with a good spec of the syntax but without semantics. Thorsten
Hence the item #2. Consistency models should be discussed at GGF. The group should find out a) Are there any error conditions or features that need to be added to SAGA in order to support existing consistency models. b) What are the ramifications of the existing consistency models on the high-level programming interface that is being offered by SAGA? How will it affect the way an app writer must implement error checking & recovery? This is, in effect, an exploration of the semantics that are imposed on SAGA by available/underlying implementations for remote I/O. -john