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-----
