Gregg, On 2011-01-06, at 11:10 PM, Gregg Vanderheiden wrote:
>> Our users are going to want to feel a sense of autonomy over their >> preferences profiles. They're going to want to have the choice of keeping >> their preferences "close to the hip," stored locally on their mobile device >> or in their desktop browser. They're also going to want the flexibility of >> keeping their preferences in the cloud, accessible to a wide variety of >> applications and Web services without having to manage lots of separate >> profiles, logins, or account information. > GV: Colin - why all the discussion on this. Did something happen? What > you seem to be protesting - was never the plan. Can you fill me in? This has been a long thread, and some of the background has inevitably gotten lost in the shuffle. I think the best way to clarify all of this is write up a bit more detail about what we're talking about. I'm going to volunteer to start a wiki page describing the architectural issues for preferences storage in its various forms, and then suggest a plan for next steps. Since we need to move on this soon for FLOE and the Infusion 1.4 release anyway, now seems like the perfect time. Once I've written some more detail in the wiki, we'll have something tangible to discuss. In the meantime, let me reiterate my position: * Preferences storage should be about choice: a distributed, cloud-based approach to preferences storage, along with the ability to store preferences locally in the browser or on a USB stick. * At the moment, OpenID the only solution for distributed single sign-on used by real people on the real Web, so we'll want to be able to work with it in our architecture, despite its flaws. * Our architecture should absolutely not be tied exclusively to OpenID, nor any other single authentication scheme. >>> As I stated, what I would prefer is the HTML 5 local data storage approach >>> with a browser add on. This plug-in would also synch up with GPII when a >>> preference store is available. For this: >>> >>> - A user has full control over who accesses the preferences >>> - Preferences can be accessed by web applications directly from HTML 5 >>> constructs >>> - A user can configure preferences locally in their browser >> > > GV: how does this work on public and shared systems? > > GV: I can see browser as portal but not as storage (except on the personal > devices we say area vanishing). Am I missing something? Seems like it, yes. Here's an example of a local browser preferences storage use case: "Joey has a computer set up at home. An assistant has helped him get all the assistive technologies he needs installed on it. He's also been helped with the process of setting a GPII preferences profile. Since Joey's computer is perfectly tuned to his needs, it's the system he uses to access the Web most of the time. Joey wants be able to allow certain Web sites to access my styling and UI preferences, so that they can deliver their Web applications in the way he finds easiest to use." As Rich as pointed out, HTML5 Local Storage and a browser add-on are a good solution to enabling Web applications to transform their user interfaces based on a user's GPII preferences without having to rely on a third-party storage server. As I said in my previous email, it's not a suitable solution for public workstations such as those at libraries or community centres. Hope this helps, Colin --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
