You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@geode.apache.org by Jacob Barrett <jb...@pivotal.io> on 2017/01/23 18:05:48 UTC

Proposal to Coalesce Java and Native Client Config

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

Re: Proposal to Coalesce Java and Native Client Config

Posted by Ernest Burghardt <eb...@pivotal.io>.

+1 for common point of reference!

On Mon, Jan 23, 2017 at 10:09 AM, Anthony Baker <ab...@pivotal.io> wrote:

> Are there any differences between the client-cache element in Geode vs
> Native XSD?  Seems like a really good idea to use a single, common schema.
>
> Anthony
>
> > On Jan 23, 2017, at 10:05 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > 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
>
>

Re: Proposal to Coalesce Java and Native Client Config

Posted by Jacob Barrett <jb...@pivotal.io>.

There are some differences. The Java version has several items that are
very Java centric. There are also some items that probably need to be
implemented in the native clients. Most the other items, like pools,
servers, region, etc. are pretty much the same.

I think it would be worth having a detailed look into what a unified
extensible config would look like.

-Jake


On Mon, Jan 23, 2017 at 10:10 AM Anthony Baker <ab...@pivotal.io> wrote:

> Are there any differences between the client-cache element in Geode vs
> Native XSD?  Seems like a really good idea to use a single, common schema.
>
> Anthony
>
> > On Jan 23, 2017, at 10:05 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > 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
>
>

Re: Proposal to Coalesce Java and Native Client Config

Posted by Anthony Baker <ab...@pivotal.io>.

Are there any differences between the client-cache element in Geode vs Native XSD?  Seems like a really good idea to use a single, common schema.

Anthony

> On Jan 23, 2017, at 10:05 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> 
> 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

Re: Proposal to Coalesce Java and Native Client Config

Posted by Michael William Dodge <md...@pivotal.io>.

I think this is a good idea: it reduces an unnecessary and potentially confusing redundancy.

Sarge

> On 23 Jan, 2017, at 10:05, Jacob Barrett <jb...@pivotal.io> wrote:
> 
> 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