On 05/11/2011 09:14 PM, Zhenhua (Gerald) Guo wrote:
There are two ways how Shindig SPIs are implemented.
1) Implementation of Shindig SPI directly accesses RAVE database to
get whatever information it needs.
Disadvantages:
- Shindig and RAVE portal must be placed on the same machine.
Why can't we access the Rave database remotely?
- Database access code may be duplicated in both Shindig SPI
implementation and RAVE code.
Duplication of the code is undesirable, but if we package the database access
logic as a separate module it can be "shared" or used by both.
2) RAVE portal exposes OpenSocial services (e.g. GetPerson, GetAlbums)
and implementation of Shindig SPI calls them (instead of accessing
database directly).
Advantages
- Shindig and RAVE portal can be run on separate machines
- Database access code is maintained in only one place.
Disadvantages:
- Security concern may arise.
Any comments about which one is better?
Another tough question :)
Both do have advantages and disadvantages, but from a scalability POV my
preference probably would go to the first one. That way only the portal is
dependent on Shindig (or other widget containers) but not simultaneous also the
other way around.
One (very large scale) scenario I can envision for instance is leveraging
sharded NoSQL database instances where (only) subsets of users a served by a
particular Shindig instance and then only need a (near) local database with only
data for that subset. If however the Shindig needs to access the portal instance
it either forces all this load to one portal or we will have to devise our own
sharding logic. I'd prefer delegating such functionality to backend services
which already are good at that (e.g. databases).
But of course, more criteria might need to be taken in consideration to decide
on the right course here.
From a practical POV, I would expect using database access from Shiding for now
should also be easier/quicker to implement (assuming the common database access
logic is factored out in a separate module).
And, as this database access layer is needed by the portal already anyway, there
is little effort lost if we later on would decide to implement and leverage
OpenSocial services from the portal instead.
Anyone else with an opinion or feedback?
Ate
Gerald
On Tue, May 10, 2011 at 11:42 PM, Zhenhua (Gerald) Guo<[email protected]> wrote:
I just created a JIRA sub-task for OpenSocial Person related SPI implementation.
The Person object is specified in OpenSocial spec 2.0
http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Person.
In RAVE, we have already had User class. However, our existing User
class serves different purposes than OpenSocial Person object.
I am considering implementing Person related SPIs, at least GetPerson
SPI, if nobody else is implementing it. In the first step, I will use
our existing User class and expose basic user information (e.g.
username) to Shindig. Then I will extend User class (or write a
completely new class) to add more fields required by OpenSocial Person
data structure/model.
Any comments on this? Is the proposed implementation strategy appropriate?
Thanks,
Gerald
