- From: Jamie Lokier <jamie@shareable.org>
- Date: Thu, 25 Nov 2004 00:26:11 +0000
- To: Lisa Dusseault <lisa@osafoundation.org>
- Cc: Alex Rousskov <rousskov@measurement-factory.com>, HTTP working group <ietf-http-wg@w3.org>, "'simple@ietf.org'" <simple@ietf.org>
Lisa Dusseault wrote: > It's manageable from a coding point of view, I'm sure we're all > excellent coders. It's not manageable from an ease-of-use, application > design and GUI point of view, nor does it scale as far. I really can't > think how a GUI client/user can possibly manage all the ACLs on all the > node resources -- the complexity is enormous if it's not scoped down > somehow, and if it's not scoped down now, then the natural diversity of > implementations will make it much harder to scope down later. Imagine an XML document which is a web page. It seems quite reasonable to allow writing to selected portions of the page, but not to other portions or the page as a whole. That's a simple example of per-selector ACLs. There is no way a client-side GUI can handle that. ACLs of different selectors are related. In this case, a server might have logic which says a selected portion of a document is writable _if and only if_ it contains no read-only nodes. Changing permission of portions of the document would effectively modify the ACLs of other selectable portions - in ways which a generic client cannot know about. So the best a generic client GUI could do would be to try operations on a selected portion to discover if they are permitted, or query for the permitted operations on a portion before telling the user it's ok to start editing this portion. -- Jamie
Received on Thursday, 25 November 2004 00:26:18 UTC