Grouper Users - Open Discussion List

[Chris Hyzer <>]

> 
> 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:

http://php-java-bridge.sourceforge.net/pjb/

thoughts?

> 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:

etc:attributes:students:label

another

etc:attributes:faculty:label

So there is no overlap

Thanks,
Chris