chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Huebel, Jens" <>
Subject Re: folder with non-accessible parent (AtomPub)
Date Thu, 13 Mar 2014 11:43:17 GMT
IMHO The spec is pretty clear on this (section

"Every folder object, except for one which is called the root folder, MUST
have one and only one parent
folder. The root folder does not have a parent.²

The question for me is also what you gain by hiding the id of the parent
folder. The client knows that there must be a parent folder. You expose
the path anyway and provide the client in this way a mechanism to retrieve
the object using getObjectByPath(). I assume this results in a permission
denied exception. What additional information is in the id that is worth
to be hidden? And doesn¹t a file system behave also in a way that you see
the parent but don¹t have access?


On 13/03/14 09:03, "Florian Müller" <> wrote:

> Hi Florent,
> The spec doesn't really clarify this case.
> Here is my personal gut feeling:
> I think there should be an "up" link because every folder in CMIS must
> have a parent folder. So a client could expect an "up" link.
> Accessing the parent should throw a permissionDenied exception in your
> case, though. I guess that would also match the behavior of the other
> two bindings.
> - Florian
>> Hi,
>> In some of our applications a given folder (a user's workspace) has
>> internally a parent that exists but is not accessible to the
>> particular user. Therefore we return no parent for it.
>> However Chemistry assumes that only the root can have no parent:
>> org.apache.chemistry.opencmis.client.runtime.FolderImpl.getParents
>> checks if it's not the root, and if not calls
>> which fails as there's not rel="up" link.
>> What do you think? Is what we do illegal according to the spec, or is
>> it just Chemistry that has to be patched?
>> Florent

View raw message