Grouper Users - Open Discussion List

[Chris Hyzer <>]

> Some comments on the page:
> - How many groups do you assume a user has? How many uses will a group
> have? Some of the features you propose seem a bit tricky if you have
> say, several 1000's of users and a equivelent number of groups.

I don't make any assumptions, we have a fairly large deployment where it took 
work with the existing UI to make it work well for large groups or people 
with a large number of groups.  I believe we have all that figured out.  If 
there is a query you need to run, let me know, it is probably possible.  The 
one gap that I hope to fix at some point is it is not possible to sort and 
page a large membership list by a person's name.  This is because the subject 
API could be ldap and would need to fetch all members (something that goes 
against paging).  I think the fix is to store a little more info (which could 
get a little stale) in the grouper_members table so we can have a sort string 
to join in one query.


> - What do you mean with 'Will not (at least initially) have information
> about immediate/effective, will be simple'?

I mean, you cant see why a member is a member, i.e. which groups are in which 
groups which makes the result that the user is a member.  You will only see 
if they are a member, and removable.

> - 'Externalized text' will allow for translations?

Yes, at least one, but hopefully resource bundles so you could have multiple

> - the ability to filter the user list is required if the number of
> users
> is large

Right

> - Why introduce new, undocumented WS and not just use the ones already
> there? If you feel these are currently not sufficient, would it not be
> a
> better idea to fix that problem (so fix the ws's)?

Well, yes, I will use the existing calls when possible, but in some cases 
not.  It would be great if the existing or augmented WS could be used for a 
UI.  However, in this UI all communication to the server will be WS.  So when 
I need to get the templates or externalized text, etc, it doesn't make sense 
to have a generic WS for that.  There is no WS for searching subjects (we 
need to add this).  Also, I need to get up and running quickly and on 1.4.2, 
so I wont have the opportunity to change any WS.  Finally, I picture needing 
to tweak the information in/out for the UI, and versioning the WS is tedious 
and I try not to change them once a version of grouper is released.  But 
hopefully this exercise will identify some ways to expand the current WS to 
make it more powerful.  E.g. we will add a json2 format (assuming one person 
out there wants to keep the existing JSON... I would be surprised and 
sympathetic if anyone happens to be using that :) ).

> One feature that seems to be missing for me is the ability to provide
> federated authentication as a basis for login into the gui.

How would this work?  I think you need a custom subject source where you can 
enter in ID's, and then link that up on login.  It would be better if the app 
could add new authenticated users to the custom source table so there is no 
mistyping.  I think this would not be hard unless there is more to it.  :)  
Penn is in process to shibbolizing, once we are I can do a proof of concept.  
How do you picture it working?

Thanks,
Chris