Fantastic writeup! Just two quick things... On Tue, May 6, 2008 at 1:45 PM, Lieven Dekeyser <[EMAIL PROTECTED]> wrote:
> Hey, > > For the past few weeks we've been working on integrating Shindig with > Netlog. Our sandbox is finally live on > http://en.netlog.com/go/developer/opensocial (If you don't have a Netlog > account yet, you'll have to register first) > > Cassie and others asked us to leave a few notes on our implementation: > > The basic steps are surprisingly straightforward: > > - Provide implementations for the interfaces in > org.apache.shindig.social.opensocial.* > For Netlog, we're just using our internal API to request the data, so the > opensocial services basically make calls using our java client-side api and > reformat the output for Shindig. We haven't implemented Netlog-specific > calls yet, it's just the basic opensocial stuff for now. > > - Inject our implementation using guice > We have one guice module which injects our GadgetTokenDecoder, > PeopleService, DataService and ActivitiesService implementations. This > required us to replace both the CommonGuiceModule and SocialApiGuiceModule > (code injections cannot be overridden), so we also had to inject > BasicRemoteContentFetcher, BasicContentCache and the OpenSocialDataHandler. > > As far as the build process goes, maven is not my cup of tea, so it's kinda > hacked together for now: > - Using svn:externals properties, we import a specific revision (right now > r653446) of the shindig repository in our working copies. > - Before building, the Shindig working copy is patched with a diff file > stored in our repository to represent our local changes. Amongst other > changes, this patches the web.xml file to use our guice module in stead of > CommonGuiceModule and SocialApiGuiceModule. > - After patching, Shindig (java/server) is built, our own *Service > implementations are built and the resulting jar files are put in the war > folder before running. > > The sane thing to do would probably be to create our own pom.xml that > "installs" our jars in the local maven repository and add it as a dependency > to the server pom file, but I haven't had the time or courage to look into > this. > > We're using Jetty to test, and Tomcat in production. > > > Pieter De Schepper did the gadget rendering part, and these are his notes > about gadgets.js: > > - in the gadget render function: added appid and set the current view > - made the serverBase configurable > - some html changes to use our layout > - change in userprefsmenu toggle (toggle: show userprefsmenu, hide gadget) > > > A few questions that came up while testing: > > At first, Shindig didn't seem to pass the compliance test gadget (default > url in our sandbox), but after adding one line to > features/opensocial-0.7/jsonperson.js to indicate the type of dateOfBirth, > it works: > >> JsonPerson.constructObject(opt_params, "dateOfBirth", Date); >> > > Has this just been overlooked, or is this change somehow incorrect? just an oversight(see the todo in the file :), i'll fix this. > > A lot of gadgets from opensocialdirectory.org and the photostatus sample ( > > http://opensocial-resources.googlecode.com/svn/samples/photostatus/trunk/photostatus.xml > ) > don't work as they require opensocial-0.5. Are the specs backwards > compatible, and if so, shouldn't Shindig handle opensocial-0.5 compatible > gadgets with the opensocial-0.7 implementation? shindig supports 0.6 and 0.7 right now and will shortly also support 0.8 we don't have support for 0.5 cause the code wasn't written until 0.6 was already live. we could maybe write a js translation layer like we did for the 0.6 apis and put that into shindig so that we support 0.5 as well. i don't remember off hand what the diffs from 0.5 to 0.6 were but if it is important to you guys you might want to give it a shot. as an example, here is the translation from 6 to 7 http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-0.6/opensocial6to7.js you would just need to write a 5 to 6 one (or 5 to 7 i suppose) let me know if you have any questions. > > There seem to be problems with the initial height of gadgets. It seems that > if an initial height is set in the gadget's xml, it's not passed through > correctly by Shindig. Also, a lot of gadgets don't seem to call > _IG_AdjustIFrameHeight() after initialization. Is there anything we can do > to make sure gadgets are displayed correctly? > > Lieven Dekeyser > Desktop Application Developer > > Netlog NV > Emile Braunplein 18 > B-9000 Ghent > Belgium > > > >
