> [ Greg pauses for a moment, considers, then punts on any deep
> or thinking about such a nasty design problem. "later" he thinks... ]
> On Wed, Sep 05, 2001 at 11:49:50AM +0200, Sander Striker wrote:
>>> From: Bill Tutt [mailto:email@example.com]
>>> I'm going to slightly reorder these points to help discussion.
>> You forgot to put '3. Ordering' in. [sidenote: if you are going
>> to respond to the concept, please reply to the original mail
>> with all the points in it]
> Why should they all be in there? Maybe he had nothing to say about it.
> Trimming down the email is best -- no reason to include the whole mo'fo'
> thing just to talk about a few portions of it.
Right. My bad. The sidenote was there for future replies so that
other points would not be forgotten.
>>> Why do there need to be so many privileges? Can't we simplify this to
>> Annotate is not a read access operation is it?
> Sure it is. Why would you think it isn't a readonly operation?
> Ah. You're probably thinking "apply annotations". In this case,
> "annotate" is used to mean "annotate each line of a source file
> with who changed it and when." Look at the "annotate" facility
> in ViewCVS, or the "blame" concept in Bonsai.
Ah. Confusing term "annotate".
>> I think splitting out the priviliges in svn terms might be a
>> good thing. The [outdated] section in the design doc speaks
>> of defining roles which is exactly what could be achieved by
> Cover up underlying nastiness with yet more concepts. Bleh.
That is the downside ofcourse.
> In practical terms, read, write, and admin are the only things needed.
I'm sceptical about this being fine grained enough. Ofcourse,
we'll just have to see if it is [it could very well be].
>> I don't think it is that simple. Or I must be misreading it.
>> However, this already takes us into the details I tried to avoid in
>> the beginning of the discussion. Lets move this to somewhat further
>> in the thread when more people have had their say.
> If people apply some thought to it and generate a thread :-)
> -Greg "Happy with Apache authz for 1.0" Stein
Oh, I am also perfectly happy with apache authz for 1.0, I just
want to make sure the 1.0 code leaves enough room for complicated
authz to be added [I currently think it does].
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:40 2006