Hi again, attached is another revision of the SAGA Core API Experience document, which contains changes as discussed at OGF28. I hope the changes reflect the discussion points. The complex stack of SAGA implementations, their interdependencies, the fact that interop is weakly defined for APIs, and the fact that GFD.90 specifies the SAGA API in a language independent way, al those things make it somewhat difficult to come up with a concise definition of the goals for our interop document. While there is little doubt in the group that SAGA is implementablt, we should strive to make that point convincing in the document. So I'd like to invite you all to review the document in that respect, and help to improve those points if possible. In particular, I added some short description of the language bindings (not implementations) -- it would be great if Hartmut, Ceriel and Mathijs could shortly review those sections, and fix/expand where appropriate. Quoting [Thilo Kielmann] (Mar 15 2010):
2. the SAGA Core experience document
Andre was walking the group through the upcoming experience document. The discussion lead to the following action items:
clarify the notions of interoperable vs. compliant what do we need/want to show exactly?
done
remove section 2, there seems no real value here
done
section 3: was debated as well solution: merge its content into the current section 4
done
make more concise points about what we want to test, exactly
attempted ;-) Quoting [Thilo Kielmann] (Mar 16 2010):
1. presentation by Go Iwai about the SAGA implementations done by the Japanese NAREGI project. They identified several (fortunately small) issues with the spec.
It was decided to incorporate their findings in the errata document and to close the list of errata then. (We are not aware of another mature implementation effort from which we have not received errata feedback yet.)
done So, a couple of additional errata from the Naregi group have been applied to the Core API - hopefully the last ones. However, there remains one item unresolved: appearently we never considered to add a flush() method to the saga::file instance. As is, our API implies that all writes are immediately flushed. While that is certainly valid, the question remains if we should consider an explicit flush() method, which would, amongst others, allow implementations to perform client side caching of write operations. Iff that is considered useful, one could further discuss if that should be introduced on namespace level, so that other namespace derived packages (replica, advert, etc) can also benefit from flush(). FWIW, a close() should always imply a flush() IMHO. So, please voice your opinion! Best, Andre. -- Nothing is ever easy.