You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Niels van Dijk <ni...@het.net.je> on 2010/03/10 23:04:54 UTC
Stacking OpenSocial Containers
Hi,
Has anyone every tried to introduce a persistent data layer in a
container based on another OpenSocial containers content?
This could be done by implementing a php or java OpenSocial client in
the persistent data layer to consume a remote container's rest api.
It would for example be interesting for combining a local set of users
and groups with a remote set, or to create a 'mashup' of 2 remote
containers.
If anyone has any experience with this I would love to hear what was
done to make this work.
thanx!
Niels
Re: Stacking OpenSocial Containers
Posted by "Jacky Wang (王超)" <ch...@google.com>.
Hi Niel,
Great to get your reply. Please find the comments inline as below.
On Fri, Mar 12, 2010 at 6:05 AM, Niels van Dijk <ni...@het.net.je> wrote:
> Hi Jacky,
>
> Thanks for your response, please find some comments and ideas below.
>
> Jacky Wang (王超) wrote:
> > Very interesting idea.
> >
> > Actually I've personally put some efforts on this idea. Some challenges
> > I've faced includes:
> >
> > 1. Latency. Since these 2 containers might not locate in the same data
> > center (in most of the cases), the data fetching latency could be a
> serious
> > issue.
> >
> >
> These will very likely not be in the same datacenter, I agree. So that
> would mean the 'local' containers client should perhaps introduce
> caching of some sort? I have not really tested this (yet), but I assume
> a 'getPerson' would not pose a problem, but something like
> 'getallgroupmembers' might?
>
Agree. Cache will play a vital role in this circumstance.
Another important part might be batching. Actually in the most case
'getPerson' is pretty lightweight, but one thousand 'getPerson' at the same
time could be a disaster.
>
> > 2. Security. There need to be some kind of secure tunnel between the 2
> > containers, plus ip-whitelist filtering.
> >
> >
>
>
> > 3. Authentication. Given the data request flow is Client -> container1
> ->
> > container2, it introduces two authentications. Unless there's a tight
> > business deal signed by container1 and container2 that they trust each
> > other, it will be difficult for the client to push the authentication
> > credential (for container2) through Client -> container1 step.
> >
> >
> True for both points. The containers would need 'federation', e.g. much
> like in between google wave servers.
> For my scenario that would not be a problem, but it might be a problem
> in a more generic scenario.
> I am looking at this from the perspective of the science and educational
> communities. In these communities, authentication federations, already
> requiring both trust and secure transfer of attributes are already
> common place, so the ground rules for such a trust relation between
> containers are already there.
>
This federation needs remarkable work on re-factoring the authentication
part of Shindig. Some hints/thoughts are:
1. does container1 knows the mapping from user@container1 to user@container2
?
2. Shindig handles its authentication in 3 ways: anonymous, url parameter
(st token), and oauth (2-legged or 3-legged).
3. The same situation happens when the client initiates a "remote fetching"
request using MakeRequest call. Which OAuth consumer key you'll use -
container1's or container2's?
>
> > 4. Incentive. If container2 already has a Shindig installed, they may
> have
> > much less incentive to connect it to another container (as front-end).
> >
> >
> Well, suppose company/university A and B are cooperating in some sort of
> 'virtual organization' (VO), and they both want to offer some OpenSocial
> based collab tools to the combined set of users. If the VO shindig would
> be able to get users and other attributes from the local A and B
> shindigs, it could offer apps specifically targeted at the collab effort
> between A and B, without the need to duplicate user, group and other
> data from two local shindgs nor the need for either A or B to do
> difficult stuff to allow for example A's users on B's shindig but still
> shield B's 'sensitive' widgets that are B only.
>
That's true. "Virtual organization" idea is very interesting and
attractive.
>
> You stated in the beginning of this message that you've already been
> working on this. May I inquire what your use cases are/were, and if that
> resulted in any usable code already?
>
It's just an experiment, from Oct 2008 to Feb 2009. One idea is setting up
a Shindig instance for each party might be a bit too heavy. Apache Abdera
could be a good alternative.
Hope it helps.
Regards,
Jacky
>
> many thanks,
>
> Niels
>
> > Just my $0.02. Hopes they helps.
> >
> > Regards,
> > Jacky
> >
> > On Thu, Mar 11, 2010 at 6:04 AM, Niels van Dijk <ni...@het.net.je>
> wrote:
> >
> >
> >> Hi,
> >>
> >> Has anyone every tried to introduce a persistent data layer in a
> >> container based on another OpenSocial containers content?
> >> This could be done by implementing a php or java OpenSocial client in
> >> the persistent data layer to consume a remote container's rest api.
> >> It would for example be interesting for combining a local set of users
> >> and groups with a remote set, or to create a 'mashup' of 2 remote
> >> containers.
> >> If anyone has any experience with this I would love to hear what was
> >> done to make this work.
> >>
> >> thanx!
> >> Niels
> >>
> >>
> >>
> >
> >
> >
>
--
Best Regards,
Jacky Wang
(Office) +86-10-6250-3316
(Mobile) +86-1381-0018-677
Kejian Building, Tsinghua Science Park Building 6
No.1 Zhongguancun East Road, Haidian District
Beijing P.R.China 100084
Re: Stacking OpenSocial Containers
Posted by Niels van Dijk <ni...@het.net.je>.
Hi Jacky,
Thanks for your response, please find some comments and ideas below.
Jacky Wang (王超) wrote:
> Very interesting idea.
>
> Actually I've personally put some efforts on this idea. Some challenges
> I've faced includes:
>
> 1. Latency. Since these 2 containers might not locate in the same data
> center (in most of the cases), the data fetching latency could be a serious
> issue.
>
>
These will very likely not be in the same datacenter, I agree. So that
would mean the 'local' containers client should perhaps introduce
caching of some sort? I have not really tested this (yet), but I assume
a 'getPerson' would not pose a problem, but something like
'getallgroupmembers' might?
> 2. Security. There need to be some kind of secure tunnel between the 2
> containers, plus ip-whitelist filtering.
>
>
> 3. Authentication. Given the data request flow is Client -> container1 ->
> container2, it introduces two authentications. Unless there's a tight
> business deal signed by container1 and container2 that they trust each
> other, it will be difficult for the client to push the authentication
> credential (for container2) through Client -> container1 step.
>
>
True for both points. The containers would need 'federation', e.g. much
like in between google wave servers.
For my scenario that would not be a problem, but it might be a problem
in a more generic scenario.
I am looking at this from the perspective of the science and educational
communities. In these communities, authentication federations, already
requiring both trust and secure transfer of attributes are already
common place, so the ground rules for such a trust relation between
containers are already there.
> 4. Incentive. If container2 already has a Shindig installed, they may have
> much less incentive to connect it to another container (as front-end).
>
>
Well, suppose company/university A and B are cooperating in some sort of
'virtual organization' (VO), and they both want to offer some OpenSocial
based collab tools to the combined set of users. If the VO shindig would
be able to get users and other attributes from the local A and B
shindigs, it could offer apps specifically targeted at the collab effort
between A and B, without the need to duplicate user, group and other
data from two local shindgs nor the need for either A or B to do
difficult stuff to allow for example A's users on B's shindig but still
shield B's 'sensitive' widgets that are B only.
You stated in the beginning of this message that you've already been
working on this. May I inquire what your use cases are/were, and if that
resulted in any usable code already?
many thanks,
Niels
> Just my $0.02. Hopes they helps.
>
> Regards,
> Jacky
>
> On Thu, Mar 11, 2010 at 6:04 AM, Niels van Dijk <ni...@het.net.je> wrote:
>
>
>> Hi,
>>
>> Has anyone every tried to introduce a persistent data layer in a
>> container based on another OpenSocial containers content?
>> This could be done by implementing a php or java OpenSocial client in
>> the persistent data layer to consume a remote container's rest api.
>> It would for example be interesting for combining a local set of users
>> and groups with a remote set, or to create a 'mashup' of 2 remote
>> containers.
>> If anyone has any experience with this I would love to hear what was
>> done to make this work.
>>
>> thanx!
>> Niels
>>
>>
>>
>
>
>
Re: Stacking OpenSocial Containers
Posted by "Jacky Wang (王超)" <ch...@google.com>.
Very interesting idea.
Actually I've personally put some efforts on this idea. Some challenges
I've faced includes:
1. Latency. Since these 2 containers might not locate in the same data
center (in most of the cases), the data fetching latency could be a serious
issue.
2. Security. There need to be some kind of secure tunnel between the 2
containers, plus ip-whitelist filtering.
3. Authentication. Given the data request flow is Client -> container1 ->
container2, it introduces two authentications. Unless there's a tight
business deal signed by container1 and container2 that they trust each
other, it will be difficult for the client to push the authentication
credential (for container2) through Client -> container1 step.
4. Incentive. If container2 already has a Shindig installed, they may have
much less incentive to connect it to another container (as front-end).
Just my $0.02. Hopes they helps.
Regards,
Jacky
On Thu, Mar 11, 2010 at 6:04 AM, Niels van Dijk <ni...@het.net.je> wrote:
> Hi,
>
> Has anyone every tried to introduce a persistent data layer in a
> container based on another OpenSocial containers content?
> This could be done by implementing a php or java OpenSocial client in
> the persistent data layer to consume a remote container's rest api.
> It would for example be interesting for combining a local set of users
> and groups with a remote set, or to create a 'mashup' of 2 remote
> containers.
> If anyone has any experience with this I would love to hear what was
> done to make this work.
>
> thanx!
> Niels
>
>
--
Best Regards,
Jacky Wang
(Office) +86-10-6250-3316
(Mobile) +86-1381-0018-677
Kejian Building, Tsinghua Science Park Building 6
No.1 Zhongguancun East Road, Haidian District
Beijing P.R.China 100084