API Council : What should we do about unlogged/anonymous viewers? +Proposal
Fabricio Zuardi
I have a question about something that doesn't seems covered by the
current version of the API (0.5) or at least not part of the online
documentation.
Since this api as far as I understand is a work in progress, and since
this is an *open* api, it is natural to expect that improvements
suggested by the community, after some discussions and an agreement
can land into future revisions before we reach a good stable version
that can be frozen (1.0 maybe).
I believe that this mailing list is (or if not, should be) the
main/authoritative place to discuss API improvements and decisions, as
open as possible, following the good path of other standardization
efforts in the open source community. So I will prefix this types of
request with "API Council" in the subject to make filtering easy, I
don't think we need another list for that just yet :)
Enough talking, my first rant: anonymous or unlogged viewers. What
should we expect from a container? Is this something we want
OpenSocial API to cover? And if so, how?
Context
--------------------------
For big profile-centric social networks today, like Myspace, Facebook,
Orkut, Friendster, etc that are closed, and/or invitation-only, due to
the nature of this business and privacy concerns, an account and being
logged-in is required in order to view anything, so it is fair to
assume that a gadget/app placed on someone's profile page will always
have as the Viewer a known member of that network, so the current
available checks isOwner and isViewer covers everything.
However, other more public accessible and not so profile-centric
social networks like Flickr, Deviant Art, Last.fm, LinkedIn to some
degree and public networks built on top of the Ning platform, not
necessarily requires login to access and view user pages, and so,
application developers needs to know what to expect from the api under
this circumstances, otherwise it will have to test on every network to
see how that particular container have implemented the "anonymous
viewer" case and make lots of checks in his code to be able to work
cross-networks. And we don't want that.
Use case
------------------------
* I am an application developer and want to display the list of
friends of the viewer in my application following the example of the
Developer's Guide at
http://code.google.com/apis/opensocial/docs/javascript/index.html
* I also want to prepare my code to behave different in case the
viewer doesn't have an account on that network, be it to display a
message "sorry, but you need to be a member", or to fallback and show
the owner's friends list for unlogged users.
* Since there is not a clearly defined method to check if the viewer
is logged, or an standard expected value for the
newFetchPersonRequest, I have to go and test on all containers one by
one and adapt my code for the different ways containers might treat
unlogged users, for example, Ning as of today returns a Person of name
'Anonymous' and id 'xn_anonymous'. I am pretty sure this is not a
standardized value because XN is a ning namespace, not a documented
return value ;)
Proposal
----------------------
- Add a new method to the Person class
http://code.google.com/apis/opensocial/docs/javascript/reference/opensocial.Person.html
:
Boolean isLoggedIn()
- The anonymous user would still be a Person instance, which means
that a dataResponse.get('viewer').getData(); would return an object
and not false or null, the reasoning for that is that an anonymous
user is still a person (jokes aside) and it might as well have a name
like "Anonymous Coward" on slashdot, a generic avatar, and an id that
is different depending on the network.
- this is different than just checking if the list of friends is
empty, because an app developer might want different behaviors for a
registered user with zero friends and an unlogged user.
What do you guys think? Does that make sense? Is this approach
reasonable? I would love to hear your toughts on that.
--
Fabricio C Zuardi
http://cchits.org
Robson Eisinger
We don´t have to take literally the "Open" from OpenSocial. I believe
that is important to respect the privacy concerns and your approach
sounds nice to me and very reasonable.
Also, considering the Social class, I guess the viewer/owner are still
unclear. In the Twitter application
(http://estradacms.com/opensocial/twitter.xml) when I accessed my
profile I get my data from twitter. So I tried to access the Twitter
from a friend's profile and again I get my data. =)
Cheers,
Robson Eisinger.