The principle of such mapping is quite simple, you have to support the id, name, thumbnail url, and profile url and all the rest is optional.
If you want a complete list of all fields you could support, you can either check out the model included in php shindig (shindig/php/src/social/models/Person.php) or view the spec definition of the person object: http://wiki.opensocial.org/index.php?title=Opensocial.Person_%28v0.9%29 The classes that need to be implemented are the (shindig/php/src/social/spi/) PersonService, ActivityService & AppDataServer, and the workings of them is pretty straight forward too, getPerson is called with a user id, group id and optionally the fields that are desired, which can be empty in which case you return the default set, id, name, thumbnail url, profile url, or '*' for all available fields and you return a person object (see the model i referred too above).. The same goes for getPeople(), except that you return a RestfulCollection which contains the collection of Person's. For all functions the way to communicate errors is to throw an (SocialSpiException) exception, with an description and either a not_implemented, internal_error, unauthorized or not_found error code, which shindig translates to the correct error format (which format that is depends if it's a REST or JSON-RPC call, but thanks to the abstraction you don't have to worry about that). The scope in which the request happens is defined by the token, it has an owner, viewer and app id which you can use to define your data privacy restrictions. And .. if you want a practical example of all of this, just check out partuza/Shindig/PartuzaService.php, which implements all of the stuff i've described above. So that's the social data mapping, and if you also want to host gadgets, then you need to implement iframe generation (see partuza/Application/Views/gadget/gadget.php) where you have to deal with user preferences, lang & country values, view, width, height params and creating a proper security token (see http://www.chabotc.com/partuza/about-partuza-and-shindig-security-tokens/for some details on that). I'm afraid that the practical example partuza gives you is the best documentation we have at the moment, but believe me before I started on Partuza the best available was "examine shindig's sources and try to reverse engineer what it expects of you", so it's not nearly as bad anymore as it could be :) If you run into any specific issues with implementing, please feel free to jump on the shindig-dev mailing list for support: http://incubator.apache.org/shindig/community/getting-help.html -- Chris On Mon, Jul 20, 2009 at 2:50 PM, rbruhn <[email protected]> wrote: > > Well, I'm giving up for now and admitting some defeat.. lol > I examined the Partuza code and can understand most of what is > happening. I just don't have time to read through all the classes and > figure out how to map my existing database fields to variables > required for opensocial. Unless there is some place out there with > sufficient documentation explaining such mapping? > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
