Proposal to refactor site membership

[Ray Davis]

Currently the only way to create a "real" 3akai site (i.e., one that
will work as expected) is through the browser. The necessary steps
(creating folders and groups for the site roles, adding the current user
as a member with the "Collaborator" role, etc.) are executed as a series
of client-side JavaScript calls from
"/devwidgets/createsite/javascript/createsite.js". Only the first call
is actually to the "SiteService". The others are chained, one request
being sent to the server after the previous one returns. There are 13 of
them (well, 14, but one of them always fails in my tests) -- you can see
them all in one spot in "createSite" in my test data loader:

https://source.sakaiproject.org/svn/msub/berkeley.edu/gnr3/trunk/loaddata/src/main/java/org/sakaiproject/gnr3/testing/Gnr3HttpTestBase.java

This was a great way to bootstrap a proof-of-concept, but it's not
sustainable:

- "Create a site" is a single user action and should result in an atomic
operation. The domino line of client-side calls can be interrupted at
any point by network problems (or the user's impatience) and result in a
effectively corrupt site.

- Automated testing of site creation is impractical. (Not coincidently,
the main reason I ended up working from saved binary builds of K2 was
that site creation so often failed when I tried to build from source.)

- The implementation details of site roles and permissions (what they
are and how they're described, how they're mapped to and from
Jackrabbit-groups, what permissions they get) are mixed up with what
should be UX code ("create a site", "display member info"). Any changes
require editing multiple client-side JavaScript files. And our
requirements tell us that we _will_ need changes.

- Because of the split, the Jackrabbit groups created to hold site
memberships are not deleted when the site is deleted. Among other
things, this means that you'll get an error if you then try to create a
new site with the same ID. (Integration tests pointed this one out in a
hurry!)

Even restricted to the server-side, we see some non-DRY warning signs,
with the SiteService throwing away "roles" knowledge that the
SiteMembersServlet needs and the SiteMembersServlet effectively redoing
the work.

If no one has objections, I'd like to enter a JIRA to refactor and
consolidate this logic server-side. If the current SiteService owner is
OK with it, I'd be glad to attempt an patch myself.

(An obvious next step would be to relocate roles configuration to the
site template, but I think consolidation of the currently functionality
makes sense first.)

Best,
Ray

[Ian Boston]

Ray,

You don't need a jira or a branch or permission to do this work. If
you think its important and you think you can do it in a way that
a) works with what else is there
b) works with those involved both on the UX and the Backend

then go ahead.

I cant give you any guarantees that what you produce will be
acceptable, but I am prepared to help you make it acceptable as I have
done with others. I also can't give you any guarantees that other work
in this area in the back end will stop while you do your work. In fact
I can guarantee you that work will continue, and you should be
prepared to patch your code base if there are changes.

The best way to avoid disappointment is to share on list what you are
doing, ask questions, and be prepared work with others.

On your last comment in brackets I think a more detailed proposal is
in order. (relocating roles configuration to the site template)

Thanks
Ian

[Ray Davis]

> The best way to avoid disappointment is to share on list what you are
> doing, ask questions, and be prepared work with others.

I thought that's what my previous message was for, but I could be wrong.
:) FWIW, though, I'd prefer to open a JIRA ticket before starting so
that the work can be tracked (or taken over) by other interested
parties. Hope that's OK....

Thanks,
Ray

=

[Clay Fenlason]

It sounds like there are multiple patches imagined here, some for K2
and some for the UX work that (I think) is still a branch in
subversion. It probably doesn't help if we're treating the two sides
of things in different ways, and the collaboration on the K2 work in
github seems to be stronger than the coordination of distributed
coding for the front end.

That said, I wouldn't want to assume that we should simply adopt K2
practices for the UX work, on the general principal that those
patterns of development may differ considerably.

wdyt?

~Clay

[Ian Boston]

On 26 Oct 2009, at 21:13, Clay Fenlason wrote:

>
> It sounds like there are multiple patches imagined here, some for K2
> and some for the UX work that (I think) is still a branch in
> subversion. It probably doesn't help if we're treating the two sides
> of things in different ways, and the collaboration on the K2 work in
> github seems to be stronger than the coordination of distributed
> coding for the front end.
>
> That said, I wouldn't want to assume that we should simply adopt K2
> practices for the UX work, on the general principal that those
> patterns of development may differ considerably.
>
> wdyt?

At he moment the UX work is following a patch queue, and those
managing the patch queue are frankly finding it hard work. Thats why
all of the SAKIII jiras talk about merge into SVN. They have 2 options
to make this scale.
1. Stop reviewing patches, open up UX svn to all comers and manage
conflicts post commit.
2. use something else that make the process work (no guesses what I
might recommend if asked)

I *will* channel the discussions I have heard around 1, and that is
that the UI work is so sensitive at the moment, that those taking
responsibility are extremely wary of stopping doing full patch review
before commit, but as this effects them, I have cc'd Christian and
Oszkar who are working in this area so they can give you their
thoughts directly. (not certain if they are on this list)

Ian

[Clay Fenlason]

What timing! I hope to meet these individuals in person this week.

I think as we push into a coordinated effort to implement Sam's
designs we'll need to take up this code management issue, and find a
solution that can be both distributed and well-managed. I think Eli
and Ray are going to have more valuable patches as time goes on, and I
think it's our collective hope to see the pool grow even larger. We'll
of course also want to be alert to the fact that Oszkar and Christian
are under pressure to have things working well in production over the
near term, and that may be a part of the present caution, but I think
there are ways to answer both sets of concerns.

At any rate, something to talk about.

~Clay

[Ray Davis]

I've contributed patches to both K2 and UX, and I have Git branches for
K2 work and a Subversion branch for UX work, so I guess that aspect of
this particular issue doesn't seem too scary to me. If I end up
contributing a patch for K2, I'll link that JIRA ticket to a JIRA ticket
and patch for UX (as I hope to do soon for KERN-345). AFAIK right now
the UX patch would consist entirely of removed code and speedier
performance.

That said, I'd love to see some thought put into better coordination of
"K2" source and "UX" source in 3akai. At present the two are fairly
closely linked in functional terms, and so they'll have to be tagged and
released together somehow. I also notice that 3akai functional
discussions seem to get scattered across sakai-kernel and sakai-ux lists
somewhat randomly.

Best,
Ray

[Clay Fenlason]

Part of the difficulty, of course, is that we haven't yet had a
community in Sakai quite like the one we imagine this one might be
(coders who don't know maven, eclipse, or Java, and don't need to).
sakai-ux has tended to be the place for non-technical design
discussion, and K2 has had its services driven directly by JSON
requirements of the UI, among other things. It's not terribly
surprising that we're not certain how to place UX development, even
our discussions about it.

~Clay

[John Norman]

We have already had a conversation about moving UX work to github and
had planned to raise it with Clay this week (today).
John