>-----Original Message----- >From: Raminderjeet Singh [mailto:[email protected]] >Sent: Thursday, September 15, 2011 10:24 AM >To: [email protected] >Subject: Re: people.create, update, and delete not implemented in rave- >shindig? > > >Following through this mail thread >(http://markmail.org/thread/atzynccews3jlsys) and the current tread closely, >helped me a lot. Matt, Are you recommending having Rave-commons having >all the models? Then we can use same model in Shindig, Rave and Wookie, >and write the data access layer individually in those components connecting to >same database.
Yes, but only need to put the ones that make sense in rave-core (soon to be created). > >Shindig and Wookie can just have methods based on SPI like getPerson >getRelation etc and In Rave we can implement createPerson and >createRelationship. All of data layer are connecting to one database for Open >social data. > >Question? >Is it Rave backend database or another opensocial database or configurable? I >will go with configurable option. If i understood from this mail >http://markmail.org/thread/atzynccews3jlsys#query:+page:1+mid:s5jt2f7rkf2 >t3uyb+state:results, Matt discussed about having it configurable. If you mean configurable in the sense that it is replaceable by integrators & implementers, then I agree. > > >Thanks >Raminder > > >On Sep 15, 2011, at 5:39 AM, Okke Harsta wrote: > >> 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----- >>> >> >>
