From MWWiki
Back to GSoC 2008
Oh and before i forget to mention, if you want to bypass the cached (for debugging), either remove the load_ from the
function name (so the magic __cal function isn't called), or remove the function name from the $cachable array.. makes
tracing things a lot easier if their not loaded from cache :)
So the flow .. as you mentioned get_application is called with the $url of the gadget (xml file), it then checks to see if
it has an up-to-date record of the gadget information in the database or not (it's a good thing to refresh the gadget info
every once in a while since they can be changed by the author).
>> select * from applications where url = '$url' and modified > $time
If the info in the DB is up to date, that info is returned
If not, it calls $this->fetch_gadget_metadata($url), and if that returns successfully, that info is stored in the DB
$this->fetch_gadget_metadata($url) uses Shindig's meta-data service to ask shindig to download the gadget & extract and
return the meta data information for it ... title, directory title, thumbnail, author, width, height ... etc. It does this
by creating a request with a json encoded request:
$request = json_encode(array('context' => array('country' => 'US', 'language' => 'en', 'view' => 'default', 'container' =>
'partuza'), 'gadgets' => array(array('url' => $app_url, 'moduleId' => '1'))));
And sending that to shindig:
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, Config::get('gadget_server') . '/gadgets/metadata');
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_AUTOREFERER, 1);
curl_setopt($ch, CURLOPT_MAXREDIRS, 10);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 4);
curl_setopt($ch, CURLOPT_TIMEOUT, 20);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, 'request=' . urlencode($request));
$content = @curl_exec($ch);
And returning the resulting json_decode()'d information:
return json_decode($content);
That is returned to the get_application function, which as mentioned above checks to see if an error is set, and if NO error
occurred it stores that info in the DB and returns that application information.
Do note that the gadget_server has to be configured correctly (full URL leading up to the /gadgets... part), else the meta
data requests will fail.
Now since all of this happens behind a few layers of abstraction and caching, it can make debugging the meta data request a
bit tricky, what i do instead is use the meta-data sample to see the actual requests being made in firefox + firebug .. that
way if that gives an error, it'll be easy to see:
http://modules.partuza.nl/gadgets/files/container/sample-metadata.html
If you can't add applications, my first guess would be that either the gadget_server URL is missconfigured, or something is
going wrong in the meta-data interface, the second thing being easily verifiable by hitting your local http://<shindig>
/path/gadgets/files/container/sample-metadata.html and checking out the results in firebug.
You could also put a :
file_put_contents("/tmp/debug.txt", $content);
In the fetch_gadget_metadata function after the curl_exec() call, so you can inspect the result more closely.
If that still fails, copy the fetch_gadget_metadata code and paste it in a seperate test.php file, where you echo the curl
result codes and response body... seperating out the logic sometimes makes debugging a lot easier, and since it has no
application deps (it's a simple curl function) that's very easy to do.
So about the Service files, well OpenSocial says that it is completely according to spec to respond NOT_IMPLEMENTED to
pretty much all requests, so while it wouldn't make for an interesting situation, you could just respond not implemented to
every request, and still call your self 'open social compliant' :)
I'd say to have a somewhat useful integration you need to implement atleast:
- PeopleService (no people makes social boring:P)
- AppDataService (used a lot by apps)
- A container javascript that responds & performs set_title, resize and set_pref:
http://code.google.com/p/partuza/source/browse/trunk/html/js/container.js
(notice that set_pref is a RPC function and not a social-api call in shindig .. so you have to implement how to deal with
this in joomla, see partuza's setpref controller & that JS function for inspiration)
With those basics you'd have a pretty good platform already .. you'd have to find out how to translate Joomla's users to
owner and viewer ID's (viewer and/or owner can be anonymous though, but as mentioned, social things are more fun when you
have the concept of a user), and add a simple persistent storage for the app data and app preferences.
Activities is 'nice to have', but possibly not completely suited for joomla (though you could store them but just not show
them ... but it would allow for apps to use it & future joomla coders to use that info in their modifications)
And messages ... hardly any currently live OpenSocial platforms support sending messages, so not a problem at all to skip
that one :)
Let me know if i rushed through things to quickly and i need to expand on any of these things & hope it helped a bit!
-- Chris
