Ryan was referring to a specific gadget blacklist capability available in
the container, not necessarily to allowing the allow/deny on the features
list, though of course it could be used in any of the cases.
It would seem that if you want to add additional administrative attributes
to a generalized store, that you might also need to identify the attributes
being added.
{
"default" : {
"http://www.google.com/ig/modules/horoscope.xml"; : {
"features" : {
allow: ["views", "tabs", "setprefs",
"dynamic-height", "settitle"],
deny: null // null blocks all, empty array
blocks none.
}
},
"http://www.labpixies.com/campaigns/todo/todo.xml"; : {
"features" : {
allow: ["setprefs", "dynamic-height",
"views"],
deny: null // null blocks all, empty array
blocks none.
}
},
"http://www.example.org/badgadget.xml"; : { "blacklisted" : "true" }
},
"foo" : {
"http://example.com/gadget.xml"; : {
allow: ["tabs"],
deny: null // null blocks all, empty array blocks none.
}
}
From: Dan Dumont/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 09/01/2011 09:36 AM
Subject: Re: Replacing The Gadget Blacklist Functionality
What about a slight tweak to allow both behaviors in one file
{
"default" : {
"http://www.google.com/ig/modules/horoscope.xml"; : {
allow: ["views", "tabs", "setprefs", "dynamic-height", "settitle"],
deny: null // null blocks all, empty array blocks none.
},
"http://www.labpixies.com/campaigns/todo/todo.xml"; : {
allow: ["setprefs", "dynamic-height", "views"],
deny: null // null blocks all, empty array blocks none.
}
},
"foo" : {
"http://example.com/gadget.xml"; : {
allow: ["tabs"],
deny: null // null blocks all, empty array blocks none.
}
}
Where order is to apply all deny rules before allow rules (allow will
override)
From: Ryan J Baxter/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 09/01/2011 10:22 AM
Subject: Replacing The Gadget Blacklist Functionality
As I look into how to add more functionality around gadget administration
into Shindig (https://issues.apache.org/jira/browse/SHINDIG-1601) I came
across the gadget blacklist which can be enabled/specified in
shindig.properties. I am wondering what people think about combining that
list into a more general gadget administration store. For the work I am
doing around administrating the features and RPC services a gadget is
allowed to use I have created a sample store in shindig, which is really
just a JSON file. (You can replace this file via a guice module.) Here
is an example...
{
"default" : {
"http://www.google.com/ig/modules/horoscope.xml"; : ["views", "tabs",
"setprefs", "dynamic-height", "settitle"],
"http://www.labpixies.com/campaigns/todo/todo.xml"; : ["setprefs",
"dynamic-height", "views"]
},
"foo" : {
"http://example.com/gadget.xml"; : ["tabs"]
}
}
In essence this JSON file specifies which features each gadget is allowed
to use in a given container. If a gadget requests a feature not in the
array for that container the metadata request will fail for that gadget.
You could also easily provide the same functionality the blacklist
provides based off the information in this store, the store pretty much
acts like a whitelist where the administrator needs to specifically allow
gadget to render in a given container and provide the features that gadget
is allowed to use. Obviously this is the inverse of what the blacklist
did, but I don't think it makes sense to have to maintain two lists.
Thoughts?
-Ryan
Email: rjbax...@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
