[sldev] Re: [ARCH] Permissions

Andre Roche roamingryozu at gmail.com
Tue Sep 25 05:39:08 PDT 2007


On 9/25/07, John Hurliman <jhurliman at wsu.edu> wrote:
> Argent Stonecutter wrote:
> > From: John Hurliman <jhurliman at wsu.edu>
> >> To get something close to that would require a change in how content is
> >> delivered to clients.
> > [...]
> >> The discussion about trusted/untrusted domains really has nothing to do
> >> with this as the weak link in the chain is the clients
> >
> > What part of "I know that, this is not a 'technical solution', it's
> > like a 'speed limit' sign" do I have to explain again THIS time?
>
> Speed limits work not because there is a sign on the side of the road,
> but because there of patrolling officers and radar/laser guns and court
> fines. There is a very good discussion to be had here about social
> solutions to the problem, but I don't think it affects the evolution of
> the architecture technical spec. As long as the system is extensible
> enough that people can implement a fake permission system on top of it
> there should be no worries.
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>

A fake permissions system?  I don't think any described implementation
of a permissions system is 'fake.'  Permissions are a lot like
"Rules."  Rules can be ignored, but they should be followed.  It's a
word with a social definition regardless of any technical
implementation.

American Heritage Dictionary -
(pər-mĭsh'ən)
n.
   The act of permitting.
   Consent, especially formal consent; authorization.

 I do agree the architecture should be extensible.  The real question
here is, should a basic permissions system be the standard, and how
basic or advanced should it be.

With that question in mind, is there good reason why at least a
cursory permissions system with cursory enforcement by the official LL
client shouldn't be standard, aside from the DRM just doesn't work
argument?


More information about the SLDev mailing list