I think B makes sense unless there is a documented need for C. Perhaps there should be a note somewhere in DRMAA2 mentioning C as a potential future DRMMA3 activity. Dan On May 19, 2011, at 10:44 PM, Peter Tröger wrote:
Dear list,
after long discussions during this week's phone conference, I decided to make a public poll about a basic decision in the DRMAA2 design.
So far, DRMAA1 + DRMAA2 assume that all API activities are performed by one application using the library. The authorization for using the DRM through DRMAA is derived from credentials of the user running the application. Therefore, DRMAA did not need an understanding of authorization in the API so far.
With the introduction of advance reservation (AR) as part of the API, some people reported that ARs are typically created by 'dedicated' managing users, and consumed (in terms of job submission) by other users. This breaks our old principle, since some DRMAA application instances now prepare DRM resources for other 'users'. You can easily extend this to a maybe necessary relation of 'resources' (machine, queue, AR), and users allowed to operate with them.
We would like to know from you if the upcoming DRMAA2 should
A) continue to treat authorization as implicit. This would not allow to create ARs for other users. B) allow to create ARs for other users, but keep the implicit user assumption for all other activities. C) should generally consider that there are user-related rights for resources and activities in the DRM.
Option A is currently implemented, option B would be inconsistent but easy to solve by adding one attribute (ReservationTemplate::usersACL), option C demands another major restructuring of the new API.
Please state your choice on the list - we need a quick decision here.
Thanks, Peter. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- Daniel S. Katz University of Chicago (773) 834-7186 (voice) (773) 834-6818 (fax) d.katz@ieee.org or dsk@ci.uchicago.edu http://www.ci.uchicago.edu/~dsk/