Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Namespace Transition

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Namespace Transition

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Barton <>, Shilen Patel <>
  • Cc: Grouper Dev <>,
  • Subject: Re: [grouper-dev] Namespace Transition
  • Date: Mon, 05 Jan 2009 10:44:10 +0000

--On 29 December 2008 09:23 -0600 Tom Barton

Thanks for getting this started, Shilen.

I imagine two general use cases. In one, copies are made as a
convenience. A "template" group, stem, or hierarchy is created, and
copies are made to flesh out some scheme. For this, the copies have new
identifiers and would optionally inherit memberships held by template
Sometimes it will be fine if the extension / display extensions are copied verbatim, however, it may be useful to have a means of changing the extensions as they are copied e.g. prefix / suffix / regular expression / interface. In general I like to have unique extensions - though in the QuickStart we don't.

The second general case occurs when the names originally chosen for some
groups or stems need to change while maintaining references to the old
names, at least for a while. This might occur because names of
departments, teams, or organizations have changed (merged, split, or just
renamed). It might also be due to a change in the authority of who can
create what. For example, initially a group within the Dean's Office
manages a group hierarchy for their College or Division, and after a
while they decide to devolve group administration across parts of the
organization. Depending on how they set things up initially, they might
need to create new substems and move or copy groups and stems to the new
ones as part of the hand-off of authority. Another example is a group
created in a personal namespace that must move to an institutional stem
to avoid being removed when the individual that created it leaves.
We did some custom development to implement aliases for stems. In part this was so we weren't restricted to one hierarchy e.g. we could have an alphabetical listing of departments as well as the organisational hierarchy, and, in some cases i.e. joint honours, some course modules would ideally be accessible from the two departments concerned. Our implementation (which used a naming convention, so I wouldn't recommend using it in the API), did allow the UI to show the aliases and would, in fact, work like a UNIX ln -s so the path displayed to the user would reflect how the user got to a location (with an option to 'relocate').

Preserving references to old names is one of the reasons aliases are
desirable. The alias doesn't change, so it's not as important to preserve
a reference to an old name. UUIDs serve this purpose, but I suppose
people don't like to use them because they are opaque. However, a flat
alias namespace maintained by grouper users can suffer from the problems
that led us to design stems in the first place: different people might
create conflicting aliases, or one can create an alias that makes the
group appear to be other than it is. Most people don't like opaque names
and tend to read meaning into lucent ones.

Whether or not we create an alias attribute of groups or stems, I wonder
if it would be worthwhile when moving a group to maintain a list of its
previous names in a system-maintained attribute of the group. Something
like the SID history that Active Directory objects have. The way this
would work is, when moving a group, the new one's name_history has its
old name added in a manner that allows the group to be selected by either
its new name or any of its old ones. Clearly, this only makes sense for
moving and not for copies. In fact, a copy of a group would necessarily
need to omit the old one's name_history.


Shilen Patel wrote:
Hi Folks,

I'm working on creating a design for namespace transition support for
Grouper 1.5.0. I've got some initial information available here.

I'm very interested to know what your use cases are so we can make sure
our requirements cover them. I'm not working from a pre-defined set of
requirements so I imagine they will be updated based on feedback.


-- Shilen

GW Brown, Information Systems and Computing

  • Re: [grouper-dev] Namespace Transition, GW Brown, Information Systems and Computing, 01/05/2009

Archive powered by MHonArc 2.6.16.

Top of Page