Public documentation doesn't give a lot of guidance, since http://sling.apache.org/site/managing-permissions-jackrabbitaccessmanager.html laconically describes the return value as "permissions in a json format."
If GetAclServlet dumped the ACL as directly as possible into a JSON array, shifting to a JSON array might be justified because the interface of the exposed object itself (the Jackrabbit ACL) had changed. But GetAclServlet instead uses an ordered map to munge multiple ACEs into a single value. Ian's suggestion of adding a sequence number to that map actually translates the object _more_ directly than an array does.
So the Sling team might consider dropping the suggested "aclarray" selector and returning only the map-with-sequence, since that simplifies the code and doesn't obscure any underlying data structure.
Best, Ray On 5/21/10 1:29 PM, Ian Boston wrote:
potential patch http://codereview.appspot.com/1229048/show Ian On 21 May 2010, at 20:28, Ian Boston wrote:Hi, I am not certain if this was intentional but the format of GetAclServlet was changed by [1]. Previously the format was a map keyed by principalid, now its an array containing objects. I can understand that an array maintains the order of the ACE's in the ACL which is required by parts of SLING-1458, however its not backwards compatible and breaks all existing clients that were expecting a map. Since that might be quite a lot of code, embedded in Client side Javascript apps and server side http clients, wouldn't it be better to provide keep the format and add a sequence number to the map objects? , eg Old format: {"user1-1274468817" : {"granted":["jcr:read"]}} New format [{"principal":"user1-1274468817","granted":["jcr:read"]}] Suggested new format {"user1-1274468817" : {"granted":["jcr:read"], "sequence": 0}} I know the suggested new format is not as natural, however it won't require all clients to recode. If we really do want to migrate to an array, then a new selector might be the way. eg ..../node.aclarray.json WDYT ? Ian 1 http://svn.apache.org/viewvc?view=revision&revision=927532
