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 <[email protected]> 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 >> >> >> > > >
