Today we have Geode XSD which contains two root elements, cache (server)
and client-cache and Native XSD that contains a client-cache. For the most
part these two schemas are the same for element client-cache. It strikes me
that it makes sense to coalesce these into a single common XSD. For areas
that need to diverge, specific to Java, C++ or .NET, the clients would use
extension namespaces similar to how the server config does can today.
Consider something like this:
<client-cache
xmlns="http://geode.apache.io/schema/client"
xmlns:java="http://geode.apache.io/schema/client/java"
xmlns:cpp="http://geode.apache.io/schema/client/cpp"
xmlns:net="http://geode.apache.io/schema/client/net"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://geode.apache.io/schema/client
http://geode.apache.io/schema/client/client-1.0.xsd
http://geode.apache.io/schema/client/java
http://geode.apache.io/schema/client/java/client-java-1.0.xsd
http://geode.apache.io/schema/client/cpp
http://geode.apache.io/schema/client/cpp/client-cpp-1.0.xsd
http://geode.apache.io/schema/client/net
http://geode.apache.io/schema/client/net/client-net-1.0.xsd"
version="1.0">
<net:appDomain enabled="true" />
<pool
name="example-pool"
subscription-enabled="true"
subscription-redundancy="1">
<java:someJavaSpecificThing name="theJavaWay" />
<cpp:someCppSpecificThing name="theCppWay" />
<net:someDotNetSpecificThing name="the.NETWay" />
<server
host="l1"
port="1234" />
<server
host="l2"
port="1234" />
</pool>
</client-cache>
This config file can now be change controlled by the customer and remain
consistent across all clients. This single file can be deployed to all
clients regardless of the client implementation language/framework.
Thoughts?
-Jake