On Tue, 05 Nov 2002 20:36:43 +0100, Roland Penning wrote:
In a corporate environment, most rolled out pc's contain the same
programs, they are imaged copies and on some pc's extra programs are
added according to the user his/her needs to perform his/her task.
What would be handy would be a centralized LDAP structure (application
not user centric) where all menu-entries and desktop-items for the
pc's can be maintained , users and groups that need to have access to
a menu-item and for KDE and Gnome access to floppy or CD-rom
(desktop-items) can can be added to the list under this item.
[snip]
After login the user will have the menu and desktop items to which
he/she has been granted access and if extra programs are present on
the pc these will be visible as well.
If a user who has extra programs on his workstation logs in to a
workstation without these additions then the extra menu-items shouls
not be visible.
So, you're going to have a menu structure in LDAP, but it isn't really,
since you munge it to fit what's present on the system. It seems MUCH
more sensible to just derive the menu structure from what's present on
the system. Look, here's actual pseudocode:
The normal way to do things:
normal_generate_menu() {
return generate_menu(list_installed_packages());
}
Your proposal:
ldap_generate_menu() {
ldap_apps = get_ldap_app_list();
local_apps = list_installed_packages();
all_apps = intersection_of_sets(
union_of_sets(ldap_apps, local_apps),
local_apps);
return generate_menu(all_apps);
}
Note that
intersection_of_sets(union_of_sets(A, B), A) = A.
So, you're doing all this work to put things into/get things
out of LDAP, but getting absolutely no return for your work.
That's not very efficient.