Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] Grouper 1.5 planning

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] Grouper 1.5 planning

Chronological Thread 
  • From: Chris Hyzer <>
  • To: "" <>
  • Cc: Tom Barton <>, "" <>
  • Subject: RE: [grouper-users] Grouper 1.5 planning
  • Date: Thu, 17 Sep 2009 10:16:07 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

> Forgive my ignorance, but how would I use the Java API in a PHP script?
> If
> that's possible I see no reason to prefer WS or REST calls. Both the
> new GUI
> and the Grouper server will run on the same machine (for the time
> being, as
> long as load will permit). Would you suggest cmd calls to grouper-
> client and
> parsing the result maybe?

grouperClient is a WS front end, so if we have no WS, then we cant use
grouperClient. We could use GSH at first, though Im afraid it is not very
lightweight, if you are making calls often, then it will be very slow and
resource intensive to startup a JVM and the grouper engine each time. We
could make you some non-built-in DB views so you could read data through SQL
(which groups have certain attributes, which attributes are available for a
group type). When assigning an attribute to a group, you could use GSH
command line, and that would hopefully be done less frequently so performance
is less of an issue... ?

Then when the web services are built, if you can keep accesses to the SQL API
isolated in methods, then maybe you could migrate to the proper WS or
grouperClient calls...

This could be a possibility, though adds another layer in there and Im not
sure how stable it is:


> My first reaction to this was "NO" I want a free-field! But then I
> realised I
> want to fetch a list of already used labels from Grouper (to offer to
> the end-
> user), so then the best (most consistent) way would be to inform
> Grouper about
> the labels used and so this solution would be only way to go?
> I assume having Grouper manage markers would enforce global consistency
> as
> well, as that would be a big advantage over keeping track of labels
> out-of-
> Grouper. Eg. removing a label from the marker list, would remove it
> from all
> groups that have it applied as well? Likewise for renaming?

Good, I agree this is a good way to go. You can manage the available labels
through GSH as well.

> Also, the Grouper instance will be used by two separate end-user
> groups, for
> which we will instantiate a different version of the GUI that will
> operate on
> a different stem. Labels of one instance should not come up in the
> other GUI
> and vice versa. My idea would be to create different grouptypes for
> that. The
> markers would have to be group-type specific then.

Right, no problem. This is a strength of the new attribute framework.

> Both groups have an attribute called "label", but should never share
> their
> list of possible marker values. But groups sharing the group-type
> should (of
> course).

Right. The attributes are fully qualified, and you can display whatever you
want to your users. E.g. one attribute:




So there is no overlap


Archive powered by MHonArc 2.6.16.

Top of Page