Groupware requires ways to define users and groups, test for membership in groups, and manage users’ preferences and group affiliations. In this chapter we’ll explore these issues while developing a notification system that alerts a group of subscribers to docbase updates. We’ll also build a family of group membership modules that share a common interface but talk to different data stores.
Internet groupware presents special opportunities and challenges,
because it can encompass scopes as narrow as a few individuals and as
broad as the entire wired planet. To build groupware applications for
these environments, you’ll need various kinds of directory
services. A directory can model human resources, such as users and
groups, and other resources, such as a computers, printers, networks,
and offices. Applications that consult a directory don’t have
to create their own directory information or provide their own tools
to manage it. And yet the world is full of applications that do just
that. Why? Even within companies there has never been a single
standard for directory service. Of course, there are plenty of
standards, including Unix’s
/etc/group, NetWare 3’s bindery,
NetWare 4’s NetWare Directory Service (NDS), NT’s
Security Accounts Manager (SAM) database, the Windows 2000 Active
Directory, the VINES StreetTalk service, and many others.
From the perspective of a LAN-based groupware application—cc:Mail, for example—there were ...