Re: [cmis] [OASIS Issue Tracker] (CMIS-786) Symbolic Link Extension Proposal

[kenb <kenb@ccs.neu.edu>]

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.

-- Ken

> > Symbolic 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