What we did in the SURFconext project - and this is also how some of the potential customers are thinking of using it - is to have the portal and shindig use the same database (e.g. Person table). The Open Social clients can use the osapi or 2/3 legged rest/rpc interface to retrieve information and the update/create functionality is provided by the portal (or in our case a provisioning framework based on federative identity). I think the project adoption would benefit from an similar approach. If both shindig and rave use the same backing data repository then it is easier for clients to replace this with an implementation which taps into some existing datasource.
On Sep 14, 2011, at 10:04 PM, Raminderjeet Singh wrote: > I added my comments inline. > > On Sep 14, 2011, at 12:03 PM, Franklin, Matthew B. wrote: > >>> -----Original Message----- >>> From: Marlon Pierce [mailto:[email protected]] >>> Sent: Wednesday, September 14, 2011 11:56 AM >>> To: [email protected] >>> Subject: Re: people.create, update, and delete not implemented in rave- >>> shindig? >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Gerald reminded me that we had this discussion before >>> (http://markmail.org/thread/atzynccews3jlsys). Assuming a shared DB >>> between Rave and Shindig, how does new OpenSocial information get >>> pushed into the DB? >> >> Personally, I had assumed that rave-portal would be responsible for the >> management of a Person Profile that contains a the fields available in >> Rave-Shindig. This means pulling the core model pieces out into the new >> rave-core project. If we do this, then the User in rave-portal can extend >> rave.common.model.Person, which would also replace the person model class in >> rave-shindig. >> >> Thoughts? > > > Are you suggesting we should not use rave.opensocial.model.Person in > Rave-shindig and have another model in rave commons? Then have a service to > sync or transfer the data. We have all the opensocial models in shindig > already which we may use like Friends, Relationship, Messages etc to provide > opensocial data in Rave for user to collaborate or share gadgets . Shindig > already provide the API to expose that to Gadgets using OAuth token i guess. > > I will split this into 2 different pieces > > 1. How we populate all the opensocial tables in Shindig? I agree with you > these table can be made part of Rave or extend in rave to make it simple but > that will make Rave as a close system and then we need to find out what to > share externally and what to hide. > 2. We need share the opensocial data to gadgets or external services(like > with user Facebook profile) based on some security token. This API is > provided by Shindig itself according to me or some part of it. We may need to > extend that in some way if needed. > > Do i sound right? > >> >>> >>> >>> Marlon >>> >>> >>> On 9/14/11 11:25 AM, Franklin, Matthew B. wrote: >>>>> -----Original Message----- >>>>> From: Marlon Pierce [mailto:[email protected]] >>>>> Sent: Thursday, September 08, 2011 3:25 PM >>>>> To: [email protected] >>>>> Subject: Re: people.create, update, and delete not implemented in rave- >>>>> shindig? >>>>> >>>> This is a limitation the Shindig API for PersonService >>>> (org.apache.shindig.social.opensocial.spi.PersonService). Matt >>>> implemented the API's get methods in DefaultPersonService, but to >>>> implement updatePerson requires a change to the Shindig interface. >>>> >>>>> I didn't see resolution on this issue. IMO, Rave-portal & rave-shindig >>> should share the same database instance for the demo application and in >>> minor deployments. Internally, we plan to do what we did with OSEC & Rave, >>> which is to define a common person service that both applications pull from. >>>> >>>> >>>> >>>> How should we proceed? >>>> >>>> >>>> Marlon >>>> >>>> >>>> On 9/8/11 2:32 PM, Marlon Pierce wrote: >>>>>>> We need a way to update the rave-shindig database from >>>>>>> rave-portal--for example, when a new user is created. I assume >>>>>>> this should be done through the OS API with rave-portal calling >>>>>>> shindig via REST or RPC API. However, it looks like person.create, >>>>>>> person.update, and person.delete are not implemented; person.get is >>>>>>> working ok. >>>>>>> >>>>>>> Assuming I'm not making a simple mistake, what do we need to do to >>>>>>> enable the additional person methods? >>>>>>> >>>>>>> >>>>>>> ----------------- Here is what I do: I have the following json >>>>>>> >>>>>>> { "method" : "people.get", "params" : { "userId" : "canonical" } } >>>>>>> >>>>>>> that I invoke with >>>>>>> >>>>>>> curl -H "Content-Type: application/json" -X POST -d >>>>>>> @json-person.txt http://localhost:8080/rpc >>>>>>> >>>>>>> This works ok. However, changing the method to person.create (or >>>>>>> update or delete) returns the following error: >>>>>>> >>>>>>> {"error":{"message":"notImplemented: The method people.create is >>>>>>> not implemented","code":501}} >>>>>>> >>>>>>> I realize I need to also create a authorization token and may have >>>>>>> an improperly formed JSON, but I assume these would throw >>>>>>> different errors if the service was implemented. >>>>>>> >>>>>>> I'm following >>>>>>> http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-API- >>>> Server.xml#People-Service-Create >>>>>>> >>>>>>> >>>>>>> >>>>>>> Marlon >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iQEcBAEBAgAGBQJOcM6tAAoJEEfVXEODPFIDKBIH/jx/rbHJoNYEhL2+0jjO2RjL >>> xnB0gTaPfx2jqYebNhM9L4nWJ4hWDKJv9Ps5pXowkM89oOB+BiHfHVsWoIOH >>> OHUG >>> rZgqh/pry3yX7TLhjXGkjRx+uOBInxOoxY/rPpPaqqU5UnfzW3h6tIUkZrm72daT >>> 7Op/d0jKQoX0Oqk88I5TDtLd/LeuJjYi9nJ85Hig8qukWMHpJs4n3U4286dHArjd >>> V6kfUm/PF0QYWOHzrrIVuDwX3oeVkbUkzP7D+/ZxH7hFT2iRe17XwGRORaKF >>> dhFJ >>> nc/A/V7H7QeJXMoMKvZjRRvXlrokXIG1jqy5fqN57L69PfmF5HSLlIGxUYkwQeI= >>> =QyMm >>> -----END PGP SIGNATURE----- >
