Great explanations Chris. You just made a very good start on a FAQ. This stuff should get pulled off the mailing list.
Can someone give an update on the status of http://cwiki.apache.org/confluence/display/SHINDIGxSITE/Index and if it's appropriate for this type of info? davep On Fri, May 2, 2008 at 3:59 AM, Chris Chabot <[EMAIL PROTECTED]> wrote: > Hi Lini, > > > > > 1.. first of all, who generates the security token containing the > information about the owner, viewer and token id. > > > > The social network site (SNS in short) is the one that deals with the user > information of all kinds (profiles, authentication, etc). So this site knows > who the current user is (viewer), who the page belongs to (owner), what > gadget this is (app id), which instance of it (mod id), and what preferences > a user has (things like, country, language, but also user preferences for > gadgets) .... none of this is 'created' by shindig, shindig consumes this > information and uses it. > > So how you should imagine this is that: > 1) The SNS creates a <iframe> and in the iframe url it puts a lot of info > like the security token for instance, but also the app url, id, mod id, user > preferences, etc. > 2) Shindig recieves this url, and renders the gadget based on the input of > step (1) > > > > > 2.. This token is then passed to the gadget server along with the > application url. > > > > Yes, plus some other info. > > There are 2 methods of doing this, one is that you use the methods provided > by javascript/container/gadget.js to create gadget iframe's from javascript > (feeding it the url, st, and all other info), see the example files in > javascript/container to see how to do this. > > Or you could create your own iframe's on page rendering in PHP, this means > you would include the basic files required for creating a token in your site > (Crypto.php, BlobCrypter.php, GadgetToken.php, BasicBlobCrypter.php and > BasicGadgetToken.php) and then do something like (forgive me if i make a > syntax error or 2, i just woke up and my mail program doesn't make a good > IDE) ps this assumes you fill in all the variables it uses below with info > from your database: > > // these come from your DB, the user preferences of this user / gadget / > module id combo > $prefs = ''; > foreach ($gadget_user_prefs as $name => $value) { > $prefs .= 'up_'.$name.'='.urlencode($value); > } > > // create an encrypted security token using shindig's code and the > owner/viewer/app/mod data from the site > $securityToken = BasicGadgetToken::createFromValues( > $owner, > $viewer, > $gadget_id, > $_SERVER['HTTP_HOST'], // domain > urlencode($gadget_url), > $gadget_mod_id /* first gadget on the page would be '1', second 'has mod id > 2'.. or some other identifiable number that determines which instance of the > one gadget it is (you can have multiple of the same on a page) */ > ); > > // and create the iframe url using the above info > $iframe_url = > $gadget_server_url.'/gadgets/ifr?'. > "container=default". > "&mid=".$gadget_mod_id. > ((isset($_GET['nocache']) && $_GET['nocache'] == '1') || > isset($_GET['bpc']) && $_GET['bpc'] == '1' ? "&nocache=1" : ''). > "&country=".(!empty($country) ? $country : 'ALL'). > "&lang=".(!empty($lang) ? $lang : 'ALL'). > "&view=".$view. // view of the page, like 'home', 'profile', 'canvas' > "&parent=".urlencode("http://".$_SERVER['HTTP_HOST']). > $prefs. > "&st=".$securityToken->toSerialForm(). > "&url=".urlencode($gadget_url). > "#rpctoken=".rand(0,getrandmax()); > > // Then the html to create the gadget would be: > ?> > <iframe width="<?=$my_prefered_site_width?>" scrolling="no" > height="<?=!empty($gadget_height)?$gadget_height : '200'?>" frameborder="no" > src="<?=$iframe_url?>" class="gadgets-gadget" > name="remote_iframe_<?=$gadget_mod_id?>" > id="remote_iframe_<?=$gadget_mod_id?>"></iframe> > <? > > In my experience creating your own iframe's in PHP means the page loads a > smoother (since there's no re-rendering when the page onLoad creates all the > iframe's in javascript). But that does mean your responsible for updating > the code as the spec changes or expands. > > To make a SNS you also need meta data of gadgets (title, directory title, > author, etc). Shindig provides this metadata for you, see the > sample-metadata.html in javascript/container for an example how to use this > ... Your best bet is to use CURL to connect to this service from your site, > and cache this info for 'some time' (could be from an hour to a day, but not > much longer). > > > > > 3.. Now what will the gadget server do with this token? > > > > Both the social data server and the gadget server use this token to know > who the viewer and owner is, and what the app id, mod id etc are. > > > > > 4.. If any site data is required, then the gadget server will call the > container for the data, the container will return the data as json string to > the gadget server. Is this correct? > > > > Incorrect. Shindig has 2 servers (located under /gadgets and /social), one > of the renders gadgets and provides the meta data and proxy services. > > The other is the social data interface, which provides the infrastructure > and wire format to communicate this info to your gadgets. > > To make this interface with your data source, you need to create a class > that plugs into shindig following its interface definition, see > php/src/socialdata/samplecontainer/*.php as a example of how to do this. > > The provided samplecontainer files are pretty basic as far as the amount of > information they deal with, but they should give you the right idea. > > So create your own class(es), put them inside of the socialdata/ directory > (so the auto include can find them), and edit the config.php 'handlers' bit > to the class name(s) you created. (aka something like 'handlers' => > 'MySocialDataHandler' if your class is called MySocialDataHandler, and the > file containing it is called MySocialDataHandler.php) > > > > > > 5.. Now, out of this, what has been integrated in shindig? > > > > See the bits above :) You need to create: > - the social network site (shindig isn't a SNS site, it just provides open > social functionality) > - the SNS needs to manage people, gadget info, gadget preferences etc > - load info of your gadgets in your SNS through the metadata interface > - generate the the iframe's with all the right info and security token > - create a social data interface to your own data and plug this into the > social data server > > Well then your mostly done, then you also need to create a UserPrefStore > javascript file and data backend to store preferences. The > javascript/container/cookiebaseduserpref.js has a basic implementation using > cookies, something that is nice for a demo but not for a real site... so > replace this with your own logic and your good to go :) > > > > > Can someone please reply to these points as based on this I need to start > my work. > > > > > Currently the shindig list consists mostly out of shindig developers, or > people from social network sites who already contributed too, or used > shindig and know it quite well ... which is reflected in the lack of > documentation, our apologies for that. I'm sure in the future this will > improve. But for now i hope this gave you some idea on what to do and how to > get started. > > -- Chris > > >
