Hi Karl and others, On 12 Apr 2005, at 14:00, Karl Czajkowski wrote:
Ali: I am partial to the opening idea, e.g. that the posix application element get its own user and group IDs that _only_ mean the user/group settings for the execution. I wouldn't want to see them get mixed up in more traditional notions of user, e.g. the user or "account" to which the job charges are accounted.
Yes, add me to the supporters of that idea.
Even though these will sometimes (often?) be the same string, that doesn't mean they are the same concept. I think it is better to organize the support for concepts based on how they are related to one another in use, e.g. the posix set of parameters are separated from the resource selection criteria, rather than to how they might appear similar through the haze of abstraction.
And again, I second that.
I guess I am realizing that the User section bothers me because it is trying to be a "stovepipe" abstraction among a set of more horizontal "layers" like resource selection and job configuration. I think better layers to go with these would be "authentication and authorization tokens, assertions, etc." and "accounting". Each of these may have some aspect of "userness" in them. :-/
I remember somebody (unfortunately, I forgot who it was) stating that XML is _NOT_ object oriented, and trying to apply OO based patterns to XML will bitterly fail. I think this is a classic example. (And I explicitly do not exclude myself from making that error over and over again.) Cheers, Michel