Grouper Developers Forum

["Cramton, James" <>]

Brown would of course be happy to benchmark 1.2.1 changes in Grouper and
LDAPpc. We'll even repeat our jndi vs. jdbc testing under 1.2.1. The
attentive reader may remember that our jndi connection went out to lunch
part way through our hours-long ldappc run, so we switched to a
jdbc-based person registry. I'll be interested to see how much of the
performance issue is resolved in 1.2.1. 

It's worth noting, however, that we encountered an architectural issue
under the jndi person registry that we avoid by the design of our sql
person registry. We saw java exceptions in Grouper for groups that
referenced person objects that have been purged from our LDAP directory.
It seems the subject API needs to instantiate the subject before it can
remove a member of a group. But if the subject does not exist in the
directory, Grouper produces a runtime exception when it tries to
instantiate the subject. We get around this with our sql person registry
by never deleting people from our sql registry, even if they are deleted
from our LDAP registry. We simply change their status in the sql
registry whenever it changes in the LDAP directory, so the last known
status of a deleted LDAP user is typically "deleted" in our sql
registry. For the time being, this is acceptable, but with each passing
year, our person registry will grow by 40,000 people (mostly deleted
applicants). We would prefer to use our LDAP registry as our person
source in Grouper, but before we can realistically use an LDAP person
source, we will need a means of deleting people from a group if the
person object does not exist in the directory.

Although our timeline doesn't permit us to immediately address the UI
issues we've seen in the out of the box UI, Brown is strongly, if not
adamantly in favor of working within the current struts/skins framework
to develop a more end user friendly UI. We adopted Grouper because of
its Java framework, and we've become familiar with its architecture. To
switch architecture at this point would be counterproductive. As Tom
points out, the out of the box UI is acceptable to demonstrate
capabilities for power users, but each campus may have its own UI needs.
Chances are, many campuses will have similar needs, so I suspect a
collaborative UI design review will be very useful for all interested
campuses.

James Cramton
Lead Programmer/Analyst
Brown University

401 863-7324


-----Original Message-----
From: Tom Barton 
[mailto:]
 
Sent: Thursday, August 30, 2007 1:59 PM
To: Cramton, James
Cc: Grouper Dev
Subject: Re: [grouper-dev] Grouper 1.2.0 in production at Brown

Thanks very much for this overview of where things now stand with
Brown's deployment!

Cramton, James wrote:
> What we've seen now that we're starting to get some real data is that 
> any future interface design for MACE Grouper needs to take common use 
> cases, configurability, and ACLs very seriously. For example, ...

> I know there is talk of a project to review the UI requirements. Where

> does that stand these days?
>  
> Over the next week, I will be documenting the issues we're having in 
> JIRA, complete with screen shots and analysis.

Excellent. This type of data and feedback should help us to identify
specific improvements needed for the UI.

More fundamentally, the as-shipped UI demonstrates just about *all* of
the underlying API capabilities, and without modification it's suitable
only for power users. Now several campuses are at or very near the point
at which they'd like to provide a simpler UI to a broader usership. The
question is how should one be produced? There are two main options: 
develop a second, ordinary-human usable "skin" on top of the existing UI
infrastructure (through changes to properties, struts config, and a
little custom jsp), or develop a wholly new UI application.

I'd really like to convince someone to look into the first option (new
skin for existing UI), as it seems likely to be the quickest and
cheapest way to produce a more usable UI. And developing a wholly new UI
  may have to proceed without any corresponding funding, making it a
higher hurdle.

>       20 min: Provision LDAP from MACE Grouper using LDAPpc

The fixes in v1.2.1, plus a one or maybe two line patch to ldappc to
take advantage of one of them, ought to net a substantial performance
improvement in ldappc. Might you be willing to benchmark it?


Tom