You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Marlon Pierce <mp...@cs.indiana.edu> on 2011/09/08 20:32:42 UTC
people.create, update, and delete not implemented in rave-shindig?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOaQpKAAoJEEfVXEODPFIDvSkH/3FsGwTa0/ybe95uvWHwWI/C
7Qxtl/xBUlYYJhdp/sQ+XgvJ1zf0TFUZ6XDalkPZzmM3X0184WfWHO3xddkiD3Ci
iWc0cWn6/LDJsXitZKY2QHCI7W+IUX4++ocDUIfNDqBN63ATlKRTXLzoERUTuYUN
alsO5hdCCV6Mh54zoHvnLtbSnTTpIr77D3RfzzxYH2HJ6O2SRBCFoasFjHsYMZhR
7kTObyIXn2A3HrCIcRjLgDde5mMu+SCYW/2eL4c4hJmKhFlCEnGudZ33XxD4rr0U
BYbKcgC10ZKEGPz334ygpxeam4jjeugXf1xdQJUbxmN5c2FFPyguA7AHfkdJ9GM=
=bF3t
-----END PGP SIGNATURE-----
Re: people.create, update, and delete not implemented in rave-shindig?
Posted by Ate Douma <at...@douma.nu>.
On 09/15/2011 08:27 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Raminderjeet Singh [mailto:raminderjsingh@gmail.com]
>> Sent: Thursday, September 15, 2011 10:24 AM
>> To: rave-dev@incubator.apache.org
>> 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).
An important thing to note is that moving the models to rave-commons will
introduce a general dependency on shindig-api as the rave-shindig models extend
those.
I don't have a strong opinion on that consequence yet, but would imply Wookie
(and all other provider backend implementations) will get this too, and it would
tie us strongly to a Shindig implementation. Possibly not so bad as I don't
really know of a proper alternative, but still.
Dependency management wise however I usually strive for the lowest possible
entropy, so from that POV this might not be desired.
One solution to this could be to not (yet) extend/implement the Shindig
interfaces in the rave-commons model, but use concrete Shindig extended classes
(*only* extending/implementing the Shindig API) within rave-shindig.
That is a little bit more effort, but might be acceptable.
This would then result in a provider agnostic Rave model (but strongly derived
from the Shindig model).
Note: there a few shindig model classes which actually use/depend on Shindig
specific constructs, e.g. o.a.r.o.model.Organization depending on Shindig
Address model and o.a.r.o.model.PersonProperty depending on Shindig ListField
model. These might pose a difficulty to resolve.
At any rate, I'm +1 on moving to a common Rave model as well as switching to a
single database usage.
In the current architecture this still means using two separate JPA Persistence
engine though. Unclear to me is where we stand or have opinion on moving to a
single persistence storage, e.g. like delegating one usage to the other (REST
based or otherwise).
>
>>
>> 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:mpierce@cs.indiana.edu]
>>>>>> Sent: Wednesday, September 14, 2011 11:56 AM
>>>>>> To: rave-dev@incubator.apache.org
>>>>>> 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:mpierce@cs.indiana.edu]
>>>>>>>> Sent: Thursday, September 08, 2011 3:25 PM
>>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>>> 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-----
>>>>
>>>
>>>
>
RE: people.create, update, and delete not implemented in
rave-shindig?
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Raminderjeet Singh [mailto:raminderjsingh@gmail.com]
>Sent: Thursday, September 15, 2011 10:24 AM
>To: rave-dev@incubator.apache.org
>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:mpierce@cs.indiana.edu]
>>>>> Sent: Wednesday, September 14, 2011 11:56 AM
>>>>> To: rave-dev@incubator.apache.org
>>>>> 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:mpierce@cs.indiana.edu]
>>>>>>> Sent: Thursday, September 08, 2011 3:25 PM
>>>>>>> To: rave-dev@incubator.apache.org
>>>>>>> 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-----
>>>
>>
>>
Re: people.create, update, and delete not implemented in rave-shindig?
Posted by Raminderjeet Singh <ra...@gmail.com>.
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.
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:s5jt2f7rkf2t3uyb+state:results, Matt discussed about having it configurable.
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:mpierce@cs.indiana.edu]
>>>> Sent: Wednesday, September 14, 2011 11:56 AM
>>>> To: rave-dev@incubator.apache.org
>>>> 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:mpierce@cs.indiana.edu]
>>>>>> Sent: Thursday, September 08, 2011 3:25 PM
>>>>>> To: rave-dev@incubator.apache.org
>>>>>> 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-----
>>
>
>
Re: people.create, update, and delete not implemented in rave-shindig?
Posted by Okke Harsta <ok...@surfnet.nl>.
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:mpierce@cs.indiana.edu]
>>> Sent: Wednesday, September 14, 2011 11:56 AM
>>> To: rave-dev@incubator.apache.org
>>> 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:mpierce@cs.indiana.edu]
>>>>> Sent: Thursday, September 08, 2011 3:25 PM
>>>>> To: rave-dev@incubator.apache.org
>>>>> 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-----
>
Re: people.create, update, and delete not implemented in rave-shindig?
Posted by Raminderjeet Singh <ra...@gmail.com>.
I added my comments inline.
On Sep 14, 2011, at 12:03 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>> Sent: Wednesday, September 14, 2011 11:56 AM
>> To: rave-dev@incubator.apache.org
>> 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:mpierce@cs.indiana.edu]
>>>> Sent: Thursday, September 08, 2011 3:25 PM
>>>> To: rave-dev@incubator.apache.org
>>>> 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-----
RE: people.create, update, and delete not implemented in
rave-shindig?
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>Sent: Wednesday, September 14, 2011 11:56 AM
>To: rave-dev@incubator.apache.org
>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?
>
>
>Marlon
>
>
>On 9/14/11 11:25 AM, Franklin, Matthew B. wrote:
>>> -----Original Message-----
>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>> Sent: Thursday, September 08, 2011 3:25 PM
>>> To: rave-dev@incubator.apache.org
>>> 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-----
Re: people.create, update, and delete not implemented in rave-shindig?
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----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?
Marlon
On 9/14/11 11:25 AM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>> Sent: Thursday, September 08, 2011 3:25 PM
>> To: rave-dev@incubator.apache.org
>> 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+BiHfHVsWoIOHOHUG
rZgqh/pry3yX7TLhjXGkjRx+uOBInxOoxY/rPpPaqqU5UnfzW3h6tIUkZrm72daT
7Op/d0jKQoX0Oqk88I5TDtLd/LeuJjYi9nJ85Hig8qukWMHpJs4n3U4286dHArjd
V6kfUm/PF0QYWOHzrrIVuDwX3oeVkbUkzP7D+/ZxH7hFT2iRe17XwGRORaKFdhFJ
nc/A/V7H7QeJXMoMKvZjRRvXlrokXIG1jqy5fqN57L69PfmF5HSLlIGxUYkwQeI=
=QyMm
-----END PGP SIGNATURE-----
RE: people.create, update, and delete not implemented in
rave-shindig?
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>Sent: Thursday, September 08, 2011 3:25 PM
>To: rave-dev@incubator.apache.org
>Subject: Re: people.create, update, and delete not implemented in rave-
>shindig?
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>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.17 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iQEcBAEBAgAGBQJOaRaaAAoJEEfVXEODPFID1m8H/jtNvbPngFRBUrGIyq9xLYo
>U
>kY7zpn0f+nkpuEBOalE4keDDHC77td20v9fFmS5JLhAfzvECN4bhDm8x5KDBZRgl
>sxc99PvJ+BeRZyVPtbx7E5pIAOoepJZGplUhyIvanIf2YZvh7CgDC03BhfqaeC0v
>cHnSknRZCilqti9nv+dBrKd9XUUnshR80wtFKm9cqtEHGaZYN82u+Ly+NYz2cizX
>OJk3WeXGRg+/kHjXPf203zBRaGgjf47VVFY0Qpj1E3MGGphvXhR1pzu97cId04g
>E
>lMP7krXUdMNWxdvbS9jx4KLn6z13ltnx6gKS9pI2xnoNIQpqFEdeuEyqCOeRJPQ
>=
>=DgG6
>-----END PGP SIGNATURE-----
Re: people.create, update, and delete not implemented in rave-shindig?
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOaRaaAAoJEEfVXEODPFID1m8H/jtNvbPngFRBUrGIyq9xLYoU
kY7zpn0f+nkpuEBOalE4keDDHC77td20v9fFmS5JLhAfzvECN4bhDm8x5KDBZRgl
sxc99PvJ+BeRZyVPtbx7E5pIAOoepJZGplUhyIvanIf2YZvh7CgDC03BhfqaeC0v
cHnSknRZCilqti9nv+dBrKd9XUUnshR80wtFKm9cqtEHGaZYN82u+Ly+NYz2cizX
OJk3WeXGRg+/kHjXPf203zBRaGgjf47VVFY0Qpj1E3MGGphvXhR1pzu97cId04gE
lMP7krXUdMNWxdvbS9jx4KLn6z13ltnx6gKS9pI2xnoNIQpqFEdeuEyqCOeRJPQ=
=DgG6
-----END PGP SIGNATURE-----