[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cmis] [OASIS Issue Tracker] (CMIS-786) Symbolic Link Extension Proposal
On Mon, 4 Apr 2016, Mueller, Florian wrote:
Hi Ken, When a client calls getObject on a symbolic link, what is returned? The data (properties, allowable actions, ACL, …) of the symbolic link object or the references object?
It is the referenced object (dereferencing on input) unless this behavior is disabled.
If it is the symbolic link object then the behaviour is inconsistent (-> dereferencing on input). If it is the referenced object then getChildren and getObject are inconsistent. (If a client finds an object through getChildren, the assumption is that getObject called this ID returns the same data).
Navigation services like getChildren will continue to satisfy their description: "Gets the list of child objects contained in the specified folder." The symbolic link objects are the ones that are contained in the specified folder, not the referenced objects. Symbolic link objects are not intended to be equivalent to multi-filing. One must request the object via getObject to dereference the symbolic links that are returned by a navigation service.
Best regards, -- Ken
Regards, Florian On 03/04/16 17:32, "cmis@lists.oasis-open.org on behalf of kenb" <cmis@lists.oasis-open.org on behalf of kenb@ccs.neu.edu> wrote:On Fri, 1 Apr 2016, OASIS Issues Tracker wrote:[ https://issues.oasis-open.org/browse/CMIS-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62199#comment-62199 ] Florian Mueller commented on CMIS-786: -------------------------------------- I have few questions. * Let's say a symbolic link is filed in a folder. The referenced object doesn't exist or the user has no permissions to see the references object. When a client calls getChildren on the folder, what is returned? The symbolic link object or nothing? Both are problematic.Symbolic links are only dereferenced on input, not on output. So getChildren, getDescendants and getQueryResults return the symbolic link objects, not the referenced objects. A symbolic link object has its own access policies that are independent of the access policies of the referenced object. One would discover that the referenced object does not exist or one has no permissions to see the referenced object only when one attempts to get the object. Why would this be problematic? The following could be added to the proposal to make this clear: "A symbolic link may be dereferenced only when the symbolic link object Id is specified as input to a service call. Symbolic links that are part of the output of a service call are never dereferenced. In particular, the getChildren, getDescendants and getQueryResults service calls do not dereference any symbolic links that are returned by the service call. In general, symbolic link objects are treated as ordinary objects for query operations."* If the symbolic link object and the referenced object are in the same folder and the client calls getChildren, does the repository return the object twice in the response? (If so, that might break some clients. If not, it is inconsistent.)The symbolic link object and the referenced object are different objects so this should not break a client.* How can a client identify if an object ID belongs to a symbolic link or to another object? That's necessary to decide of an updateProperties call with the disableDereferencing makes sense.There are two ways to distinguish symbolic links from other objects that are returned by a query operation (getChildren, getDescendants, getQueryResults). The simplest is that the type of the object is cmis:symbolicLink. Another way is that a symbolic link is required to have the property cmis:reference. Only symbolic links have this property. It is an OnCreate property that cannot be added, removed or modified after creation of the object.* What should happen if getDescendants or getFolderTree run into a cycle? If this throws an exception, then a single user can easily break a lot (intentionally or unintentionally).These operations do not dereference the symbolic links that they return, so dereferencing cycles should not be a problem. Of course, if the input to getDescendants or getFolderTree were a symbolic link (i.e., the input parameter folderId were a symbolic link to the actual folder), then that could result in a dereferencing cycle, but I don't think that this is what you are concerned about. In the case of getFolderTree, the results that are returned are only folder objects, so no symbolic links would be returned. -- KenSymbolic Link Extension Proposal -------------------------------- Key: CMIS-786 URL: https://issues.oasis-open.org/browse/CMIS-786 Project: OASIS Content Management Interoperability Services (CMIS) TC Issue Type: New Feature Components: Domain Model Affects Versions: Proposals for 2.0 Reporter: Ken Baclawski Priority: Minor This extension provides for a subclass of cmis:item called cmis:symbolicLink. An object of type cmis:symbolicLink has an attribute referenceId that specifies an object Id or latest accessible state identifier. When the Id of a symbolic link item is specified in a service request, the referenceId attribute of the item may be used instead of the specified symbolic link Id. The replacement of the symbolic link Id with another Id is called dereferencing. When dereferencing is performed, it is recursive: if the referenceId of a symbolic link item is itself the Id of a symbolic link item, then that symbolic link Id is also dereferenced. If a dereferencing cycle is detected, a cmis:dereferenceException is thrown. Dereferencing of symbolic links in a service call can be explicitly enabled or disabled by an optional dereferenceSymbolicLinks parameter. If the dereferenceSymbolicLinks parameter is not specified as FALSE in a service call, then symbolic link dereferencing is performed, i.e., the default value of the dereferenceSymbolicLinks parameter is TRUE.-- This message was sent by Atlassian JIRA (v6.2.2#6258) --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]