On Thu, Oct 8, 2015 at 7:31 PM, Beena Emerson <memissemerson@gmail.com> wrote: > > > Mini-lang: > [] - to specify prioirty > () - to specify quorum > Format - <name> : <count> [<list>] > Not specifying count defaults to 1. > Ex: s_s_names = '2(cluster1: 1(A,B), cluster2: 2[X,Y,Z], U)' > > JSON > It would contain 2 main keys: "sync_info" and "groups" > The "sync_info" would consist of "quorum"/"priority" with the count and > "nodes"/"group" with the group name or node list. > The optional "groups" key would list out all the "group" mentioned within > "sync_info" along with the node list. > Ex: { > "sync_info": > { > "quorum":2, > "nodes": > [ > {"quorum":1,"group":"cluster1"}, > {"prioirty":2,"group": "cluster2"}, > "U" > ] > }, > "groups": > { > "cluster1":["A","B"], > "cluster2":["X","Y","z"] > } > } > > JSON and mini-language: > - JSON is more verbose > - You can define a group and use it multiple times in sync settings > but since no many levels or nesting is expected I am not sure how useful > this will be. > - Though JSON parser is inbuilt, additional code is required to check > for the required format of JSON. For mini-language, new parser will have to > be written. >
Sounds like both the approaches have some pros and cons, also there are
some people who prefer mini-language and others who prefer JSON. I think
one thing that might help, is to check how other databases support this
feature or somewhat similar to this feature (mainly with respect to User
Interface), as that can help us in knowing what users are already familiar
