In my work at team collaboration startup, Huddle.net, we’ve encountered a number of issues with externally referenced message bundles in our Opensocial application, Huddle Workspaces.

Due to the size and scale of of the application—it’s quite big and complex in comparison to many Opensocial apps—our message bundle XML files contain a lot of content and, as a consequence, consume quite a lot of a bandwidth over the wire.

Why is this a problem? Well, it shouldn’t be, but many Opensocial containers opt not to cache message bundles, and instead request them on every application invocation. The result is that network dropouts, latency or server-load can mean your message bundles occasionally fail to reach the consumer server and entirely prevent your app from loading. End-users shouldn’t ever have to suffer as a result of server-to-server communication.

So, in lieu of consistent caching across Opensocial containers, this issue can be sidestepped by inlining the message bundle content inside your application gadget specification. This is a new feature introduced in Opensocial 0.8.1, and so you should ensure the container you’re working with is operating on a 0.8.1 codebase.

How to Inline a Message Bundle

It’s actually very simple, but it’s also something that isn’t officially documented anywhere. Opensocial development often involves shooting in the dark… but fortunately it’s well enough spec’ed that a little bit of guesswork goes a long way.

Message bundles are always referenced from the <ModulePrefs /> block in a gadget spec, and look something like this:

#Code
0001<ModulePrefs title="beardscratchers.com" author_email="nick@example.com">
0002<Require feature="tabs" />
0003<Require feature="views" />
0004<Require feature="setprefs"/>
0005<Require feature="dynamic-height"/>
0006<Require feature="settitle"/>
0007<Require feature="opensocial-0.8.1"/>
0008<Locale messages="http://beardscratchers.com/lang/ALL_ALL.xml"/>
0009<Locale lang="fr" country="fr" messages="http://beardscratchers.com/lang/fr_ALL.xml"/>
0010<Locale lang="es" messages="http://beardscratchers.com/lang/es_ALL.xml"/>
0011</ModulePrefs>
0012 

By simply removing the messages attribute from each <Locale /> element, and placing the relevant message bundle content (excluding the xml prolog), message bundles are no longer referenced externally and load along with your gadget spec:

#Code
0001<ModulePrefs title="beardscratchers.com" author_email="nick@example.com">
0002<Require feature="tabs" />
0003<Require feature="views" />
0004<Require feature="setprefs"/>
0005<Require feature="dynamic-height"/>
0006<Require feature="settitle"/>
0007<Require feature="opensocial-0.8.1"/>
0008<Locale>
0009<messagebundle>
0010<msg name="hello">
0011Hello!
0012</msg>
0013</messagebundle>
0014</Locale>
0015<Locale lang="fr" country="fr">
0016<messagebundle>
0017<msg name="hello">
0018Bonjour!
0019</msg>
0020</messagebundle>
0021<Locale lang="es">
0022<messagebundle>
0023<msg name="hello">
0024Hola!
0025</msg>
0026</messagebundle>
0027</Locale>
0028</ModulePrefs>
0029 

We’ve found that it’s much more common for gadget specs to be cached hard. Thus the additional weight of inlining your message bundle content inside your gadget XML is negated, and the application should—container-dependant—get some improvements to stability and performance.

There is one caveat. Inlining content introduces maintenance and development issues, especially if you’re running several gadget specs for different enviroments i.e. development, QA and live. In respect of this, I’d recommend keeping all your message bundles in external files and instead adding something into your deployment process that will perform the inlining as and when it is needed.

Comments for "How to inline Opensocial Message Bundles for improved performance"

Commenting is now closed for this article

About

beardscratchers.com is a music-focused web experiment and creative-arts journal from London, England.

Subscribe/Syndicate

Categories

Previous Entries…

Journal content and design are © of Nick Skelton

built with web standards and a baseline.