For discussions, I submit the following model of Scope,
Community, and Space from ICOM: http://docs.oasis-open.org/icom/icom-ics/v1.0/csprd01/icom-ics-v1.0-csprd01.html. These
containers import Role, Group, and Actor from corporate directories. Some applications
need to define Scope, Community, Space, Role, Group, and Actor (super-type of User)
for better integration of repositories. Do you envision the applications will define
these concepts as custom types in CMIS?
Figure 1 Scope
Figure 2 Community
Figure 3 Scope Types
Regards,
Eric
Chair, ICOM TC
From: Jay Brown
[mailto:jay.brown@us.ibm.com]
Sent: Thursday, June 23, 2011 8:21 AM
To: Hermes, Martin
Cc: Bram de Kruijff; cmis@lists.oasis-open.org; Churchland, David
Subject: Re: [cmis] RE: question re Users for repository vendors
In reference to Bram's mention of my suggestion
to open up the model and expose cmis:object to cmis clients. I have been
thinking about this but have just not yet had time to create a jira issue for
this discussion. I will create the issue this week and include a short description
of a possible solution that I have been mulling over for our discussion.
Jay Brown
Software Engineering
IBM Corporation
3565 Harbor Blvd.,
Costa Mesa CA 92626
+1 714 327 3431
"Hermes, Martin" ---06/22/2011 01:20:27 AM---Hi
David, we have similar requirements from a CMIS client perspective, too. To be
able to build a AC
|
|
|
|
|
|
|
|
|
|
|
|
Hi David,
we have similar
requirements from a CMIS client perspective, too. To be able to build a ACL
Dialog which allows the usage of groups within ACLs, we need to know which
groups are known by the repository. Today we have implement a ugly workaround:
The customer has to maintain the available groups of the DMS system in our
application server as well. This is error prone and increases TCO. A service to
retrieve the available groups of the repository would help much.
Regards,
Martin
From: Churchland, David [mailto:david.churchland@hp.com]
Sent: Mittwoch, 22. Juni 2011 04:01
To: Bram de Kruijff; cmis@lists.oasis-open.org
Subject: [cmis] RE: question re Users for repository vendors
Bram,
The options you
have canvassed are pretty much the same as the options I have considered. As
you identify the first option is possible today but not particularly useful
given that it is not described by the standard and would thus be invisible to
consumers.
If CMIS does
embrace Jay’s ‘super type’ I can imagine the spec describing an optional
user/group base type, this might be one way forward.
To clarify, the
problem I have is that as our Groups are not necessarily in the corporate
directory (depending on how the customer has implemented Trim) they are
effectively invisible to consumers without something equivalent to a ‘getGroups’
service. For example if there is a Trim Group called ‘All Melbourne Users’ how
will a consumer ever know this exists and thus how can they ever set the ACLs
for this group?
The impression I
got from previous discussions was that few (if any) other repository vendors
had this problem, so I am interested to see that at least one other person who
feels this pain.
Anyone else out
there? If we have one or two more maybe there will be enough momentum to
justify a JIRA issue?
Thanks,
David
From: Bram de Kruijff [mailto:Bram.deKruijff@gxsoftware.com]
Sent: Tuesday, 21 June 2011 7:38 PM
To: cmis@lists.oasis-open.org
Subject: [cmis] RE: question re Users for repository vendors
Hi David and
list,
Not sure if I
get the question entirely, but yes our product (GX WebManager) has an internal
directory as well. Mostly to support deployment models without any corporate
directory in sight, but we can also add native groups on top of external
principals. Guess that’s kind of your use-case?
So, do you want
the client to able to query for groups (through CMIS) in general or just get
access to his own groups for the current principle? Just wondering about three
possible directions.
Expose your
groups through standard CMIS /trim/groups/* as child of cmis:document. Makes it
queryable and, if I understood the discussions correctly, you can do it without
a content-stream. I guess this feels kind of awkward, probably requires some
permission juggling and it is within the spec, but not in the spec.
If I remember
correctly TRIM also has some challenges with mapping to the file/folder model?
Same here :) I think Jay suggested opening things up by exposing super type
cmis:object through allowing much more flexibility in modeling a custom domain.
This would possibly allow you to model approach 1 in a less awkward way (eg by
being able to introduce a trim:group extending from cmis:object)? In general I
am curious as to what people think about this idea! Then again, this still
would leave the repository idea outside the spec.
Adding an
optional directory capability service of some sort making it part of the spec.
It would address the TRIM challenge(?), but I guess also a deployment model
where the client does not have (enough) access to the directory (eg. from
public web) to get the required intel directly. A repository could then proxy
it. Does anyone think that is a real use case?
So, just some
thoughts. Would be happy to hear some pros and cons to these ideas as it will
help me as well in sharpening my understanding of CMIS.
Best Regards,
Bram de Kruijff
Ps. Noticed the
list does not properly set the reply-to address to the list. Known issue or can
we do something about that?
--
GX | Bram de Kruijff | Product Architect |
Wijchenseweg 111 | 6538 SW Nijmegen | The Netherlands | T +31(0)24 - 388 82 61
| F +31(0)24 - 388 86 21 | M +31(0)6 - 20 60 54 62 | Bram.deKruijff@gxsoftware.com | www.gxsoftware.com | twitter.com/GXSoftware
From: Churchland, David [mailto:david.churchland@hp.com]
Sent: dinsdag 21 juni 2011 1:09
To: cmis@lists.oasis-open.org
Subject: [cmis] question re Users for repository vendors
I am curious to see whether
our repository (HP Trim) is the only one with the following CMIS mismatch.
The only information CMIS
presents for a user is the principal ID, under the assumption that all users
(and groups) are in the corporate directory.
This is fine for people but HP
Trim uses groups extensively. These groups are not from the corporate directory
but exist only in HP Trim’s internal directory.
While for a user we can use
their login name as their principal ID I cannot determine how we could usefully
identify a group as the internal HP Trim ID is meaningless without access to
Trim, and the group’s name is not a unique identifier. Plus we have no service
to get a list of these groups.
So, for example, if we supported
groups a CMIS user wanting to apply an ACL to a Trim group would have to know
that ‘Trim_Group_56435’ is the group they want.
Does anyone else have this
model where the repository user directory is a superset of the corporate
directory? In particular where there are groups in the repository directory
that do not exist outside the repository.
If yes have I missed an
obvious solution to my problem?
If no I will just have to live
with it I suppose.
Thanks,
David Churchland
HP