On 4/29/05, Robert Larson <[EMAIL PROTECTED]> wrote: > Hello Jose, > > > I was searching for a solution for the problem of storing address book > > information, bookmarks, etc. in a centralized location (roaming user > > profiles) when I found about IMSP > > It would seem to me that what you seek is very similar to a directory service. > http://www.infrastructures.org/bootstrap/directory.shtml
Not exactly... I'm aware of directory services, and I'm already using a (Heimdal) Kerberos/OpenLDAP solution to provide authentication and authorization inside my network, but I don't think a directory service is well suited for this purpose. As you point in the excerpt taken from the document below, using OpenLDAP to store such information is "like using a heavy-duty hammer to get this particular screw attached". You may find some solutions to store that information in a directory service (I think there is some ongoing discussion or even implementation to do such a thing in Mozilla, to provide an example), but as this is not an standard way of doing it you can't rest assure the next application you will be integrating in your infraestructure will also be using the directory to store user preferences. That's why I was searching for some standard approach when I found about IMSP and ACAP, but as you say, it seems they haven't gained enough momentum to become adopted. A real pity, as I think those protocols would solve a lot of problems that people try to solve today with some really weird approaches. Thanks a lot for your response, best regards Jose > > > Is there any other standard / interoperable solution for the roaming > > profile problem? All I've been able to find seems to be highly > > propietary or non standard at all. > > Have you looked into using Samba, with an OpenLDAP backend? > www.samba.org > www.samba-tng.org > www.openldap.org > > This book gives a plethora of implementation examples including the setup and > use of roaming profiles: > http://us4.samba.org/samba/docs/man/Samba-Guide/ > > It would seem to me (after racing my eyes across those links you provided) > that this implementation may be limiting what the clients can use to only a > couple of solutions. Perhaps this is an "up and comming" thing that will be > more widely used in the future. Of course, it's also possible that this has > simply not gained enough momentum, as if it may have already been done with > other protocols, packages, etc. > > Here is a quote from the following page (dating 9-11-1996): > http://asg.web.cmu.edu/acap/white-papers/acap-vs-others.html > " The other protocols and approaches to which we are comparing ACAP in > this document include: LDAP (Lightweight Directory Access Protocol) > and directory services in general; DHCP (Dynamic Host Configuration > Protocol); SNMP (Simple Network Management Protocol); HTTP (Hypertext > Transfer Protocol); DNS (Domain Naming Service); distributed > filesystems, such as NFS and AFS; and traditional database-style > implementations, such as SQL. > > We believe in the concept of 'the right tool for the right job'. We > have no love for re-implementing the wheel, but in researching the > available options in the context of Project Cyrus, we discovered this > particular type of precision screwdriver, and trying to get one of > these other protocols -- designed for very different forms of > transactions -- is like using a heavy-duty hammer or a wrench to get > this particular screw attached." > > I hope this helps! > > Best regards, > > Robert Larson -- [email protected] mailing list
