appdata / userprefs clean up

[Mark W.]

OK... I've started work on the app data / user pref cleanup. Please take a look and let me know what you think. Given the verbal feedback from everyone so far and the fact we are coming down to the wire, I'm going to work under the assumption that everyone is genrally supportive of this idea. It might mean a bit more churn for me than usual with the edits, but I'm OK with that. 

Chris C.: You had the suggestion at one point, of using new osvars for the scoping. Because we want to do things like @friends to scope the visibility of the data, does this still make sense? Should we do both?

Issue 1182 

Thanks everyone!!!

p.s. It would be great to talk about this on the regular Thursday call, however, I've got a conflict tomorrow and will not be able to join. If folks have availability on Friday, then I'm more than happy to chat through these ideas.

[Mark W.]

I checked in the initial pass at cleaning up AppData (Revision 1423). In keeping with the spirit of simplicity, I tried to build off of the basic constructs of what was there already and not overdue it. That said, there were a number of things that I'd like to get some validation on from the community.

Because user prefs are defined in core gadget, and appdata in social gadget, it's going to be difficult to remove hidden user prefs without moving part of appdata to core-gadget. The biggest issue here is the introduction of "users" in social gadget. We can't bring any of that into core gadget, so what we'd end up with is, I think, less clarity than what we started with. I don't think we want to do this. Therefore, as much as I'd like to clean up the user prefs, I think we should leave them alone for now. 

The approach I took to "scope" appData was simply to add groupId to the update. To maintain compatibility with the way appData works today, I made the default @app. To make data private, you would use @me/@self. Likewise, you can add any group, e.g. @friends. I took this approach, in part, because groupId is already supported on AppData, although, I'd be surprised if anyone is using it. For example, you could ask for the appData of user 1234's friends, e.g. /1234/@friends. If anyone is doing this, please chime in!

Finally, there's some overlap with the spaces proposal. It's been awhile since I've gone through this, and, having thought through appData, I'm thinking we may want to make sure we reconcile the two and/or revisit it. I'm a bit concerned about the impact of the change to the existing spec. (The changes in appData alone are very significant.)

Please let me know your thoughts & Thanks!

[Craig McClanahan]

Reviewing this reminds me of a nit that you (Mark) and I have mentioned, but probably never written down.  In the description of the "escapeType" parameter on the "Get AppData" request, it says that the default is "htmlEscape".  But it does not define what that actually means (although it will probably be pretty obvious) but, more importantly, it does not provide any standard value that can be used to turn off escaping if the gadget wants to deal with that issue itself.

Craig McClanahan

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[Evgeny Bogdanov]

Mark,

about app-id mentioned before in spaces thread.
If you look at this request in OpenSocial 1.1:
http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-API-Server.xml#AppData-Service-Get,

there is an app-id in parameters. If you click on this app-id, it only opens Core-Data and there is no App-Id.
What I tried to do is to formalize this app-id here:
http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-Data.xml#Application-Id

Concerning the space the change is not that different from existing one.
The main difference is to whom data belongs.

Example with Google Map gadget.
Scenario 1: Gadget belongs to a Person profile.
Owner sets the default location. This appData belongs to owner, only owner can change it.
Optional: only owner can see it.

Scenario 2: Gadget belongs to a Space.
Any space member can set the default location for a space. This appData belongs to a space and not to a
particular person, any of space members can change it. This change is done of behalf of a space and
not a particular person.
Optional: only space members can see it.

In both scenarios there might be data that belongs to gadget viewers.
For example, comments left by viewers on Person profile or on Space page.

If there is a more granular grouping of people within Person profile (@colleagues, @friends, @followers)
or within Space (@admins, @teachers, @participants), groupId is used.
IMO, it is kind of advanced scenario and I indeed wonder whether somebody is doing it.

[Mark W.]

This is what we were trying to do with app-data. However, getting the right language around it is a bit tricky. I'm trying to avoid breaking existing app-data stuff. I like the idea of spaces because it reflects a growing need to have gadgets "owned" by a group, etc... I'm hoping we can focus on spaces and CMIS in the next go round.

As I stated before, I think the immediate need is "private" app-data--that's visible to only the viewer. Do you think there's a very simple way to do this that won't conflict with what you've got in mind?

Thoughts?