It’s not often I get to speak at a conference in my home country, The Netherlands, we just don’t have that many of them! So you can imagine I’m quite thrilled to be speaking at the Kings Of Code in Amsterdam June 30th. I’ll be covering the what the social web means, how OpenSocial can be used in this context, and touch on the various development methods like gadgets, REST API’s, Friend Connect and oh, I’ll cover Shindig too of course.

So if you’re in Amsterdam June 30th, I hope to see you there!

Update: Here’s the slides of the presentation

For this scenario we’ve created the meta-data interface, it allows you to post a gadget URL to it, and it will return a JSON structure with all the meta data of the gadget that you can use to build your app gallery, user preferences UI and create the iframe’s in your site that point to Apache Shindig (which will render the gadget for you). The quickest way to check out how the meta data interface works is by loading up the sample-metadata.html sample, and inspecting the requests using something like firebug, here’s a live example:
http://modules.partuza.nl/gadgets/files/container/sample-metadata.html

With that you have all the required info to build your site’s UI, however you also need to create the proper security tokens, and link shindig to your data source:

Security Tokens.

The gadget get’s it owner id / viewer id / app id / container string / module id from the security token, in a typical production setup this would be an encrypted blob generated by the container (ie ‘the social website’), and put on the gadget’s iframe with a &st=<encrypted blob>. Encryption ensures that that data can’t be tampered with so that people can’t spoof their user id’s etc.

Now both java and php shindig both use the same methodigy to generate their tokens (see shindig/php/src/common/{BasicBlobCrypter,BasicSecurityToken,BasicSecurityTokenDecoder}.php for example), so you really have two options, either implement the same crypto logic / format (it’s basically a text string, with entries seperated by :’s, and aes128 encryption with a shared secret) in your language of choice, or create your own crypto and implement a PHP class that can decrypt it (and tell shindig to use that new class using the ‘security_token_signer‘ and ‘security_token‘ configuration keys, similar configuration can be found in java shindig in one of it’s .xml config files), The first option is probably the simplest solution as long as aes128 is available in your language of choice.

There’s a bit more information about how security tokens work and how to implement them in this blog post:
http://www.chabotc.com/partuza/about-partuza-and-shindig-security-tokens/

Social Data.

Now java and php differ slightly here, with php you use the same configuration as I mentioned above to tell shindig which classes to use, and with java you’d use Guice to inject the right classes, but the basics are the same: You’ll need to somehow get the social data requests that happen in shindig to your data back-end.

Now when you are running php or java already this is pretty simple since you can use that code directly, however in this situation you really have two choices, either you implement the DB logic in PHP or Java (for PHP, you can use Partuza’s (an example opensocial implementation) service implementation as example: http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaService.php and http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaDbFetcher.php), or you can implement an RPC method (using something like json-rpc) where shindig relays all social data calls to your back-end.

OpenSocial and thus Shindig has 4 data call types, People, Activities, AppData and Messages; Now the spec states that the only must-have of those is the People interface, and you could return a NOT_IMPLEMENTED error code on every other call type.. However if you want to run the typical OpenSocial app, it’s advisable to also support the Activities and AppData interfaces.. Messages is a nice to have, but in practice most social sites don’t support this so it’s not a big issue at all if you don’t.

So to start off, the security token is generated in Partuza in Application/Views/gadget/gadget.php :

A bit of background: php-shindig expectes an encrypted and encoded security token, since this way you can use the cryptography to be sure that the owner and viewer ID's are not faked, a very important assumption if you don't want people to be able to spoof identities (and do naughty things like setting someone else's status update to 'i'm a big fan of poodles' (make up your own examples to get an idea of the true impact of this)).

However the out-of-the-box html samplecontainer (shindig/javascript/samplecontainer/*) uses plain text tokens, so there's support build in for this as well, but it should be turned off *as soon as possible* since it makes for a completely non-secure situation.

So Shindig does expect a "owner:viewer:appId:domain:url:modId" type token, but it can consume it in either plain text, or encrypted form.

What partuza does is generate an *encrypted* security token and it does so using the password phrases listed in partuza/html/config.php:

The shindig receives the secure token, and decodes it with it's password phrases (shindig/php/config/container.php) :

Do note that these have to be the same on both ends, otherwise it won't be able to decode the token into anything sensible, and you'll get an error code returned.

After you have this working, make sure to disable the plain text security tokens, since that's a huge wide open security hazard waiting to happen, so change this to false (in shindig/php/config/container.php)

Now the last thing that is interesting to know, is that all the classes in php-shindig that might be different between site specific implementations are completely configurable, and we provide basic examples (which are easily identified by their Basic*.php naming) which are production ready and actually see massive production usage too, but if you want to implement your own, so that you could for instance add custom fields to it, simply point the configuration to your own class, and off you go:

shindig/php/config/container.php:

That rounds up our security token tour for the day, if there's anything that I missed out on or something the shindig community can help you with, you can find us on the shindig-dev@incubator.apache.org mailing list.

The 2008 Moscow GDD in numbers:

If you just want to get to the Shindig bit, skip to the 36 min mark

The London GDD 2008 in numbers:

3000 surveys handed out
1800 candy bars eaten (conspiracy theorists united on Twitter...)
550 developers in attendance (more than 1500 applied)
60 Megabytes of internet (that never crashed and was complimented often)
44 access points for internet installed
24 Google speakers
24 Google volunteers
20 partner speakers (Hyves, Netlog, Rummble, Lastminute.com, ITN, the Met Office & the head of the Android User Group.)
17 hours of content created for YouTube.
2 giant screens that had powerpoint & code throughout the day, then Wii and Guitar Hero for the party.