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

Reply via email to