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 <[email protected]> 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 u...@container1 to u...@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 <[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 > >> > >> > >> > > > > > > > -- 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
