It's also worth noting that companies might want tighter control over what data is where. If I were setting up a corporate wave server, I might want to integrate with some user provisioning system I have in house and not use something specific to WIAB, or something public like open social.
All I am suggesting is that whatever we ultimately do by default, the system should be pluggable so that the profile information can "come from anywhere" and we have the proper controls in place to make sure it only goes where it is supposed to. This might involve defining a set of bare minimum profile information a wave server will support in a distribute manner. A set of optional profile information, and then an extendable set of information that might only be visible within a particular server implementation. ~Michael On Dec 15, 2010, at 2:49 PM, Thomas Wrobel wrote: > ah, fair point. > I hadn't considered selective visibility of certain parts of the profile. > > On 15 December 2010 22:40, Tad Glines <tad.gli...@gmail.com> wrote: >> On Wed, Dec 15, 2010 at 1:31 PM, Thomas Wrobel <darkfl...@gmail.com> wrote: >> >>> Whats the reasons against using a wave itself of some form to store >>> the user information? >>> >>> It would be somewhat neat if the same controls for who can access a >>> wave effectively become also the controls for which company's or >>> individuals can access your details. >> >> >> I'm not against it. I do think there are limitations with storing profile >> info in a wave. Consider the case where I want the public to set just my >> name and wave address, and I want other users in my domain to see my e-mail >> address and office phone number, but the admin also need me to record a home >> phone number and home address. I would not be able to put all this >> information in a single wavelet and still apply the desired access policy. >> So, I either put different bits of information in different wavelets, and >> then force client to merge the bits they can see, or I put >> the information in some other form, and provide a single API that clients >> use to access the info that filters fields appropriately based on who makes >> the request. >> >> -Tad >>
