Hello, all! I was in the process of writing a Wiki entry [1] on my experience in using the experimental cluster configuration API. While making an explicit distinction between the configuration class and any object(s) that configuration class would create, I discovered that the Extension interface is as yet internal. We have been iterating on making the configuration of the cluster in general more programmatically accessible. See [2] for the ongoing proposal, which will itself likely see much revision. The scope of this configuration API and associated refactoring has left the underlying use of XML in place, to be removed in future efforts. In the interim, however, any developer wishing to create a persisted element using our experimental configuration API will also need to implement these XML aspects of their persisted objects. To formalize this, I would like to publicize the Extension interface, as well as the related class ExtensionPoint. As iteration continues with respect to the configuration persistence service, it is very likely that the current structure of ExtensionPoints on the Region and Cache will be migrated to be handled by this or another service. However, the Extension interface will remain useful after this fact. On the one hand, it feels awkward to publicize an API that we know will not long survive the current iteration efforts. On the other hand, it feels fundamentally abhorrent to encourage a third-party developer to use an internal API. Thoughts?
Imagination is Change. ~Patrick Rhomberg. [1] https://cwiki.apache.org/confluence/display/GEODE/Extend ing+Geode+-+Creating+Custom%2C+Persisted+Cache+Configuration+Elements [2] https://cwiki.apache.org/confluence/pages/viewpage. action?pageId=75975896
