Hi Eiji & shindig-dev, (cc the second since this info might be useful
to some other people too)
the meta data service is meant to prove, well as you already guessed,
meta data information. There are a number of cases imaginable where
you want to know things about gadgets, without being a gadget renderer
your self ... and this service allows you to do that.
Your next question is a bit complex to answer because so much depends
on the type of system, how your infrastructure is setup, which choices
you need to or want to make, etc.
The first thing to keep in mind is that an open social SNS (social
networking site) has a few components:
A) The site it's self
B) The database / data source (social information, profiles, app data,
media items, etc)
C) The gadget renderer (shindig)
D) The social data interface (shindig + your own code to connect it to
B)
Now another thing to keep in mind is that security is an important
issue, the security (that gadgets can't read or manipulate (A), the
site, in a malicious manner ) is provided by the browser security model.
By the gadget and the site being on different domains, the browser
blocks all interaction between the two, so the gadget can't do
anything to your site (such as spamming, stealing passwords or
financial info, or virus like activities like auto-adding friends, and
so on).
The result of this is that you want your gadget renderer (the source
domain for the gadget iframe content) on a different host then the
site, else you don't have this security in place, and thats bad :)
However you do want your gadget to be able too:
1) Interact through a safe protocol to: resize it's content are,
request a message to be send, request the app to be shared, change
title, etc
2) Retrieve social information and set app data, create activities, etc
(1) is provided by the RPC service, there is a RPC channel (with
implementations that work on all browsers) that create such a channel
between the gadget and site, and the site implements these services
through javascript and/or it's own wire format.
See: http://code.google.com/p/partuza/source/browse/trunk/html/js/container.js
as an example of this (it does the basic services but not
request_share_app or send message etc yet).
Another example (i think they do a few things them selves that shindig
provides functionality for, but it's a good live example non the less):
http://www.hi5networks.com/platform/browser/shindig/features/opensocial-0.7/hi5container.js
(2) Is the social information.. now to be able to retrieve this it
needs to be on the same domain as the gadget domain, this is why
shindig has a social data interface (and soon also a RESTful service
interface), so this is component (D)
In (D) / (2) you create your own data interface that connects to your
own data sources, be it a data base connection, soap or xml-rpc
interface, or whatever your infrastructure has .. I've done this for
Partuza in:
http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaHandler.php
http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaDbFetcher.php
As you can see those implement the shindig standard interfaces on one
side (handler), and connects to a simple db structure on the other
side (db fetcher), shindig takes care of the rest (wire format
interaction).
To configure php shindig which interface(s) to use, change the
'handlers' => '' configuration, and link (or copy) the interface files
to src/php/social data, and you should be good to go.
Ok so now that we have the basics covered, to answer your question:
I've used the metadata interface here since i want Partuza to be a
'simple example' on how to use shindig, and in a lot of ways this is
the simplest way to hook gadget awareness up to your social site..
You could ofc have a copy of the shindig gadget rendering code on your
SNS too, and do the same as the JsonRpcHandler does:
http://svn.apache.org/viewvc/incubator/shindig/trunk/php/src/gadgets/JsonRpcHandler.php?view=markup
As long as the shindig code is a straight copy, and you use the
standard internal interfaces (so you can just update the shindig code
to keep up with the new spec's etc), there is no problem doing that.
All in all there isn't such a big difference between the 2 methods,
the first (using metadata) means you have to create a bit less code,
and your SNS isn't dealing with the load of rendering gadgets to
retrieve meta data, and the second one (rendering and retrieving the
metadata inside the SNS) you lighten the load on the shindig server(s)
a small bit. (though this is a negligible difference since shindig
will have to retrieve and cache the gadget anyhow to render it).
So either way is a valid choice in the end, and it's just that, a
matter of choice.. Hope this info helps you a bit to make your own
choices too! :)
-- Chris
On May 7, 2008, at 8:49 PM, Eiji Kitamura wrote:
Hi Chris,
Thanks for letting me know about Partuza. I've been looking at what
it's doing and I have a quick question.
What is the purpose of /gadgts/metadata on shindg side? Looks like
Partuza is asking shindig to retrieve metadata out of gadget XML.
Backend of partuza and shindig should ideally share same db and etc,
I assume.
Then, there's no need to ask shindig for gadget's metadata. Partuza
itself can fetch gadget XML and parse, doesn't it?
Is this for optimization purpose not to double implement similar
function?
Or is partuza assumed completely separated from shindig?
Eiji Kitamura
On 2008/05/04, at 1:54, Chris Chabot <[EMAIL PROTECTED]> wrote:
ps i have a live version of it here:
http://partuza.chabotc.com/
you can register there, add a gadget to your profile (OpenSocial
0.7 Compliance Tests is my favorite :) and watch it in action.
The most interesting bit for you is probably patruza/Application/
Views/applications/gadget.php .. this creates the secure token,
parses user prefs on command line and creates a gadget iframe.
Hope it's of some help
-- Chris
On May 3, 2008, at 6:47 PM, Chris Chabot wrote:
On May 3, 2008, at 6:11 PM, Eiji Kitamura wrote:
I'm still reading your code to get it work on our SNS site.
I 'm working on the side on a demo SNS site implementation:
http://code.google.com/p/partuza/
Maybe there's a few things in there that can help on how to use
shindig. (It's not done yet, but usable enough for an example i
hope)
1. I've found a bug in your code.
http://svn.apache.org/repos/asf/incubator/shindig/trunk/php/src/gadgets/ContainerConfig.php
you forgot "php" on line 1.
<?
needs to be
<?php
Nice catch, locally i have short tags enabled so i never noticed,
thanks
2. in proxy handler
http://svn.apache.org/repos/asf/incubator/shindig/trunk/php/src/gadgets/ProxyHandler.php
you "echo"es result in above code but, I prefer it to be in
ProxyServlet.php in terms of role servlet.
What do you think?
I'm not sure about this one. Normally i would agreed completely
but the handler already outputs so much (headers etc) from what
it's proxy'ing that a clean separation between handling &
outputting would take a lot more then just a return $value type
thing. I'll keep it in mind and think it over though
3. you put all $config into Config::get().
I think it's very good idea since "$config" is very common name
that when i try to import your code into our framework, name
corruption happened.
But you forgot to do it in the code below.
http://svn.apache.org/repos/asf/incubator/shindig/trunk/php/src/gadgets/samplecontainer/BasicRemoteContent.php
I think this is the only one.
Again, good catch :) Fixed in the next commit.
I'm worrying if you mind me pointing out bugs this way. Tell me
if I'm annoying you.
Not at all, I'm grateful you take the time to report them so i can
fix them!
By the way, like you had Queens day, we have holidays now, here
in Japan. It's called Golden Week. Holidays in a row like one
week :)
Lucky you a whole week, was only a day here :-) Happy holidays then!
-- Chris
