Imagine that I've added a gadget to my profile page or an iGoogle-like portal under my control. This gadget has a set of user prefs that allow me to configure how it appears on my page, and the container provides a UI for setting these preferences.
Then, I make my profile page available (read-only) to other users. You visit my profile, and you should see the gadget on my page with the preferences that I set for it. You should not be able to change the preferences, but should see whatever I set in a read-only fashion. On the container side, it's pretty easy to check whether the viewer is the owner and not display the user preferences form if the current viewer doesn't have permission to change them. Similarly, it's easy to check on the server side when persisting preference changes. So the case of interactive preference configuration through the UI is pretty straightforward. It's less clear what should happen when gadgets use the setprefs feature. Right now we're doing the server-side check, so the change isn't persisted, but then that just results in an inconsistent state on the client. Really the set call shouldn't be allowed (or should throw an exception when called). Ideally, there should be some way for the gadget author to check in JavaScript whether the current viewer has permission to change prefs so it can degrade gracefully if it's in a read-only mode. But even with those measures, it's still possible that the save to the server could fail and cause the client to be in an inconsistent state. So I have a few questions: - Is there anything in the spec that addresses permissions for UserPrefs? I couldn't find anything. - Is there any existing convention for how containers handle this situation? - Would it make sense to simply refuse to provide the setprefs feature to gadgets that are being rendered in a read-only mode? Is there any precedent for containers that provide features selectively like that rather than just supporting them (or not) globally? - More generally, how do containers handle the situation where a gadget sets a user preference and the asynchronous save to the server fails? Just make the user reload the whole page? FWIW our implementation is based on Apache Shindig for Java. Thanks, -- Tim Moore --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Implementing OpenSocial Containers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/opensocial-container?hl=en -~----------~----~----~----~------~----~------~--~---
