W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2004

Re: Some thoughts on XCAP's resource architecture

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>
Message-ID: <20041125002611.GB5730@mail.shareable.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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC