incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <>
Subject Re: -1 Against CLEREZZA-515 patch
Date Mon, 06 Jun 2011 11:48:57 GMT
I've today changed the comment of the reverting commit 1128619 for it to be
associated with CLEREZZA-515.

On Mon, May 23, 2011 at 11:12 AM, Henry Story <>wrote:

> Ok, I am answering on the list, even though I think this is really part of
> the
> discussion of the issue.
As Bertrand pointed out important changes should be discussed on the mailing
list and not just in jira.


> >> - WebId Users no longer show up in the usermanager.
> That is probably because the user manager is working on the notion of
> "user"
> as being only determined by zz:username string.

Yes, currently every user has a username, changing this breaks things.

> The WebID user is identified
> with a URI on the other hand. He does not yet have a username, and may
> in fact never desire to have a local account on your machine. Imagine all
> the
> WebID robots that may just come and fetch a page from your machine, just
> because
> they are crawling a foaf file. Are you going to give account names to each
> of them?
Yes, that's how it is currently. If we're going to have a problem with two
many users created by robots identifying with WebId to which the owner
doesn't want to assign particular permission this shall be addressed at the
given time by an appropriately described issue.

> What account names?
> The only way you can do this is by giving ugly account names to all users -
> ie: mechanically generated ones.  When  some of these users then wish to
> have
> memorable names you will then have a problem of dealing with the legacy
> names
> they were given.
Maybe. Maybe they will just have two usernames. Dropping username might
indeed be a solution, but I don't think that this is needed at the current
stage and I'm thus unwilling to accept any regression of functionality to
introduce this change. Furtermore it seems questionably that application
have to deal with instances of Subject, they should imho rather just use a
service returning a resource (GraphNode) describing the current user. You
patch changes the behaviour of current public apis, breaking client code and
without even appropriately changing the API documentation.

> >>  this is a major
> >> regression as the usage p'attern currently known to me is as follows:
> >> my friends log-in with webid and the I go to user-manager and give
> >> them additional rights
> Yes, though that is not very satisfactory in a more distributed world (it
> is fine
> for closed worlds) for quite a number of reasons:
>  1. the account control panel only shows you a small set of information
> about
>    that user. My guess is that it will just show the claimed username and
> something
>    else.
>  2. It is not declarative enough.
That a feature could be better is no reason to break it without providing a

> The better solution is to add the webids to your friends list,  and then
> have rules such as
>   "all friends of mine can do X"
> This is where I think we need to be moving towards in terms of access
> control.
I completely agree we should allow social distance based permission
granting. You can add a service that does this for user logging in with
WebId without modifying any existing code.

> So then it remains to make it easy to add people to your friends list. This
> is why
> I have been developing the person browser
> Here is the view on Dan Brickeley
> Users that do have accounts on my machine, will see little buttons appear
> that will allow
> them in one  click to add Dan as friends. That will then give Dan Access to
> all
> the things they allow their friends to access - without requiring Dan to
> have an account!
Sounds good, but shiny future feature are no reason to break existing
functionality. Furtermore I don't think social-distance based access
granting completely obsoletes assignment of permissions to individual users.

> >> - The Issue is about showing the name that is good looking, imho the
> >> foaf:Name would satisfy this requirement better than the WebId URI
> The issue is not just about the name that is displayed in the
> UserInterface.
> Of course a foaf:name can be put there. The issue is that the current
> solution
> also creates ugly account names, such as
> Account names should only be needed when people have decided to open a
> local
> account.
I think the current approach of WebId users implicitly getting an account is
fine. After the first release we might discuss alternatives, but please
discus before committing to trunk.

> >>
> >> - Even if I give all users permission to access the
> >> account-control-panel (selecting
> >>
> (org.apache.clerezza.platform.accountcontrolpanel.AccountControlPanelAppPermission
> >> "{username}" "") for the base-permission-role) Roaming Users no longer
> >> see the ACP. This is probably a problem that {username} is no longer
> >> supported.
> Yes, users without local accounts, don't have an account to look at.
> That is why I have been developing the ProfileViewer, so they can look
> at what we see of their profile as their home page, if they want.
> That page can then also ask them if they wish to create an account
> locally.

> That is the moment at which they can then choose the account name they
> prefer to have. That is an extra service that is easy to add.
Again: future feature are no reason to break existing functionality.

> >> - The resolution goes far out of the scope of the issue. I have no
> >> strong opinion on whether the larger refactoring from using Subjects
> >> instead of the UserName is beneficial. I think I'd tend to postpone
> >> such a refactoring (if it turns out to be needed) to after the first
> >> release. BUT: even if I should conclude that the refactoring is needed
> >> or even urgent this should be in a dedicated issue and not in one that
> >> addresses the aesthetics of the shown account name ("ugly")
> I think this patch addresses the full aspect of account names. The initial
> description showed the place where that ugliness appeared. But this
> is in line with the rest of my work on the authentication in Clerezza
> related to WebID.
Since you're a committer there are two issues that could actually be closed
with your patches. Doing small patches and avoid changing core functionality
would make them more easily accepted and it would also help for you getting
a feeling of how the existing features work allowing iterative development
rather than incomplete redesigns.

> >>
> >> I ask the changes to be reverted, and I volunteer that I then take
> >> over the issue.
> Perhaps it would be kind of you to trust me, as WebID Incubator Chair,
> having developed the concept for the last three years, having presented
> the concept at JavaOne initially, and so on... to give me a bit of trust
> in implementing the pieces that tie all of this together.

> Can you at least wait a few days so that others here on the list can try
> this
> out. I will put up a video showing how the pieces are meant to tie together
> and it will make a lot more sense.
> >> A solution to show the foaf:name (or atlernatively
> >> foaf:nick)  on the top-right corner shouldn't take more than a patch
> >> of a couple of lines. I show on my wall at
> >> that it is possible with
> >> existing infrastructure (the post show the foaf:name) to implement
> >> this.
> When I go there I still get the huge ugly name. But anyway, I don't doubt
> that you can replace it by a foaf:name. That is not the only issue that is
> being addressed here.
If an issue can be slitted up it usually should be slitted up. Getting the
foaf:name there would have been a small improvement, but by iterating small
improvements we can get far.

Another issue which you have adressed in CLERZZA-515 is adding a link on the
name to the account control panel. This is too a legitimate issue,
unfortunately the way you implemented it doesn't do the permission check as
the menu item does and may also provide a link to non-existing page.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message