[ 
https://issues.apache.org/jira/browse/SHINDIG-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212115#comment-13212115
 ] 

[email protected] commented on SHINDIG-1709:
--------------------------------------------------------



bq.  On 2012-02-16 22:35:47, Stanton Sievers wrote:
bq.  > I think this would make more sense to add to the existing 
gadget-admin.json file instead of into the container.js config.  It would keep 
all of the "admin" stuff in one place.
bq.  > 
bq.  > So today we have something like this in gadget-admin.json:
bq.  > 
bq.  > {
bq.  >   "default" : {
bq.  >     "gadgets" : {
bq.  >       "http://www.google.com/ig/modules/horoscope.xml"; : {
bq.  >         "features" : ["views", "tabs", "setprefs", "dynamic-height"],
bq.  >         "type" : "blacklist"
bq.  >       }
bq.  >     }
bq.  >   }
bq.  > }
bq.  > 
bq.  > You could just add another attribute that is a sibling to "gadgets" 
(name pending)
bq.  > 
bq.  > {
bq.  >   "default" : {
bq.  >     "gadgets" : {
bq.  >       "http://www.google.com/ig/modules/horoscope.xml"; : {
bq.  >         "features" : ["views", "tabs", "setprefs", "dynamic-height"],
bq.  >         "type" : "blacklist"
bq.  >       }
bq.  >     },
bq.  >     "additional_rpc_endpoints" : ["foobar"]
bq.  >   }
bq.  > }
bq.  > 
bq.  > You could read the new array on the server-side when processing the list 
of allowed endpoints from the feature.xmls before shipping that info off to the 
container.
bq.  
bq.  Ryan Baxter wrote:
bq.      Good thought Stanton!
bq.      
bq.      I think I would like to modify your suggestion a bit though.  I think 
in some scenarios it would be useful to specify the additional RPC endpoints on 
a per gadget basis, so I am envisioning something more like this
bq.      
bq.      {
bq.        "default" : {
bq.          "gadgets" : {
bq.            "http://www.google.com/ig/modules/horoscope.xml"; : {
bq.              "features" : {
bq.                "name" : ["views", "tabs", "setprefs", "dynamic-height"],
bq.                "type" : "blacklist"
bq.              },
bq.              "rpc" : {
bq.                "additionalEndpoints" : ["foobar"]
bq.              }
bq.            },
bq.            "*" : {
bq.              "rpc" : {
bq.                "additionalEndpoints" : ["helloworld"]
bq.              }
bq.            }
bq.          }
bq.        }
bq.      }
bq.      
bq.      This format lets you specify additional endpoints to allow on a per 
gadget basis.  You can use the * syntax to denote ones that should be allowed 
for all gadgets.  What do you think?

One slight change to my example...

{
  "default" : {
    "gadgets" : {
      "http://www.google.com/ig/modules/horoscope.xml"; : {
        "features" : {
          "name" : ["views", "tabs", "setprefs", "dynamic-height"],
          "type" : "blacklist"
        },
        "rpc" : {
          "additionalEndpoints" : ["foobar"]
        }
      },
      "http://*"; : {
        "rpc" : {
          "additionalEndpoints" : ["helloworld"]
        }
      }
    }
  }
}


- Ryan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3938/#review5172
-----------------------------------------------------------


On 2012-02-20 21:48:36, Ryan Baxter wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/3938/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2012-02-20 21:48:36)
bq.  
bq.  
bq.  Review request for shindig.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  If you enable RPC arbitration in a container and you want to allow a set 
of RPC service ids regardless of whether the gadgets has features that uses 
them, it is very difficult to do so. The only way to do this today is to 
provide your own arbitrator function to the common container. Essentially this 
function will do the same thing as the default implementation in the common 
container except have a list of allowed RPC service ids. It be easier if 
containers could specify a list of additional RPC services to allow on a per 
gadget basis.  It would also be nice if this was integrated into the gadget 
admin feature in Shindig already.
bq.  
bq.  
bq.  This addresses bug SHINDIG-1709.
bq.      https://issues.apache.org/jira/browse/SHINDIG-1709
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    http://svn.apache.org/repos/asf/shindig/trunk/config/gadget-admin.json 
1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/admin/BasicGadgetAdminStore.java
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/admin/GadgetAdminData.java
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/admin/GadgetAdminStore.java
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/admin/RpcAdminData.java
 PRE-CREATION 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/GadgetsHandlerService.java
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/admin/BasicGadgetAdminStoreTest.java
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/admin/ContainerAdminDataTest.java
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/admin/GadgetAdminDataTest.java
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/admin/RpcAdminDataTest.java
 PRE-CREATION 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/admin/ServerAdminDataTest.java
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/GadgetsHandlerServiceTest.java
 1245178 
bq.    
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/GadgetsHandlerTest.java
 1245178 
bq.  
bq.  Diff: https://reviews.apache.org/r/3938/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  Updated and added unit tests.  Also tested in common container.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Ryan
bq.  
bq.


                
> The RPC abritration code in the common container should allow you to pass in 
> a list of allowed RPC services for that container.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SHINDIG-1709
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1709
>             Project: Shindig
>          Issue Type: Improvement
>            Reporter: Ryan Baxter
>            Assignee: Ryan Baxter
>         Attachments: issue-1709.patch
>
>
> If you enable RPC arbitration in a container and you want to allow a set of 
> RPC service ids regardless of whether the gadgets has features that uses 
> them, it is very difficult to do so. The only way to do this today is to 
> provide your own arbitrator function to the common container. Essentially 
> this function will do the same thing as the default implementation in the 
> common container except have a list of allowed RPC service ids. It be easier 
> if containers could specify a list of additional RPC services to allow on a 
> per gadget basis.  It would also be nice if this was integrated into the 
> gadget admin feature in Shindig already.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to