You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Jason Burgess <ja...@holostek.net> on 2008/04/30 22:21:53 UTC
Questions about implementing shindig
Now that I've got a working gadget server and some basic functionality. I
seem to be getting lost in the documentation for connecting my site's data
to it.
Here's what I *think* is going to work based on what I've read. Please
correct me where I'm wrong. And there are still a few pieces of the puzzle
I'm missing, but I'll point them out along the way.
I've got a main website, www.site.com, and a gadgets server,
gadgets.site.com.
On gadgets.site.com, /gadgets is transparently proxied to the jetty server,
while /social is transparently proxied back to www.site.com/social, so that
gadgets.site.com believes it is coming from the same server.
On /social/data, I'm implementing the RESTful API to retrieve data from the
main website's database.
>From what I understood, shindig will mediate between the RESTful API and the
gadgets, but most of that isn't finished yet.
>From www.site.com, I'm implementing the container to call gadgets.site.com
to render the gadgets.
One thing I'm still having trouble discerning is where in the container I'm
supposed to be setting VIEWER and OWNER.
Hopefully, I'm at least headed in the right direction here.
Jason
Re: Questions about implementing shindig
Posted by Chris Chabot <ch...@xs4all.nl>.
Hey Lini,
Um as far as i am aware we don't have any documentation for this yet,
last time i used this i looked at the source code for it as a
reference :)
Quickly glancing over the file:
http://svn.apache.org/viewvc/incubator/shindig/trunk/javascript/container/gadgets.js?view=markup
I see that gadgets.Container has:
setParentUrl == http://mycontainer.url.com
setCountry == viewer's country (US forinstance)
setNoCache == disable caching?
setLanguage == viewer's lanuage (EN)
setView == home, profile, canvas, previews... whichever view
the viewer is on
setMaxHeight == max height a gadget can be (set this pretty high
normally, specialy on canvas view)
gadgets.IfrGadget
setServerBase == where shindig lives
Hope that helps a bit :)
On May 21, 2008, at 2:33 PM, Lini H - Clarion, India wrote:
> Hi Chris
>
> Needed one clarification regarding the parameters passed for the
> iframe generation. You have shown two method for generating the
> iframe below. I have implemented the first using the container/
> gadgets.js file using the code in the sample html files.
>
> But in none of the sample files has been mentioned what parameters
> can be passed to the gadget creating function, as i need to pass the
> st and other details. Is there any sample html file with these
> parameters as well?
>
> Regards,
> Lini Haridas
> Software Engineer
>
> lini.haridas@clariontechnologies.co.in
> Clarion Technologies
> SEI CMMI Level 3 Company
>
> 4th Floor, Great Eastern Plaza,
> Airport Road,
> Pune- 411 006,
> Maharashtra, India.
> Phone: +91 20 66020289
> Mobile: +91 9823435917
> www.clariontechnologies.co.in
> ----- Original Message -----
> From: "Chris Chabot" <ch...@xs4all.nl>
> To: <sh...@incubator.apache.org>
> Sent: Friday, May 02, 2008 4:29 PM
> Subject: Re: Questions about implementing shindig
>
>
>> 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
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
Re: Questions about implementing shindig
Posted by "Lini H - Clarion, India" <li...@clariontechnologies.co.in>.
Hi Chris
Needed one clarification regarding the parameters passed for the iframe generation. You have shown two method for generating the iframe below. I have implemented the first using the container/gadgets.js file using the code in the sample html files.
But in none of the sample files has been mentioned what parameters can be passed to the gadget creating function, as i need to pass the st and other details. Is there any sample html file with these parameters as well?
Regards,
Lini Haridas
Software Engineer
lini.haridas@clariontechnologies.co.in
Clarion Technologies
SEI CMMI Level 3 Company
4th Floor, Great Eastern Plaza,
Airport Road,
Pune- 411 006,
Maharashtra, India.
Phone: +91 20 66020289
Mobile: +91 9823435917
www.clariontechnologies.co.in
----- Original Message -----
From: "Chris Chabot" <ch...@xs4all.nl>
To: <sh...@incubator.apache.org>
Sent: Friday, May 02, 2008 4:29 PM
Subject: Re: Questions about implementing shindig
> 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
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Questions about implementing shindig
Posted by Kevin Brown <et...@google.com>.
On Fri, May 2, 2008 at 9:12 AM, David Primmer <da...@gmail.com>
wrote:
> 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?
Yes it is, but cwiki is read only for non committers due to capacity
limitations.
Chris -- if you want access to cwiki, email Upayavira.
>
> davep
>
> On Fri, May 2, 2008 at 3:59 AM, Chris Chabot <ch...@xs4all.nl> 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
> >
> >
> >
>
Re: Questions about implementing shindig
Posted by David Primmer <da...@gmail.com>.
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 <ch...@xs4all.nl> 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
>
>
>
Re: Questions about implementing shindig
Posted by Chris Chabot <ch...@xs4all.nl>.
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
Re: Questions about implementing shindig
Posted by "Lini H - Clarion, India" <li...@clariontechnologies.co.in>.
Hi all,
I wanted to clarify some points over this.
If I m developing a social site based on the open social API, i need to have both the container as well as the gadget server. Now I m a bit confused about the functions of these two.
1.. first of all, who generates the security token containing the information about the owner, viewer and token id.
2.. This token is then passed to the gadget server along with the application url.
3.. Now what will the gadget server do with this token?
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?
5.. Now, out of this, what has been integrated in shindig?
Can someone please reply to these points as based on this I need to start my work.
Regards
Lini Haridas
Software Engineer
lini.haridas@clariontechnologies.co.in
Clarion Technologies
SEI CMMI Level 3 Company
4th Floor, Great Eastern Plaza,
Airport Road,
Pune- 411 006,
Maharashtra, India.
Phone: +91 20 66020289
Mobile: +91 9823435917
www.clariontechnologies.co.in
----- Original Message -----
From: "John Hjelmstad" <fa...@google.com>
To: <sh...@incubator.apache.org>
Sent: Friday, May 02, 2008 12:13 AM
Subject: Re: Questions about implementing shindig
> Hi Jason:
>
> First off, it sounds like you're on the right track to me. A few notes:
>
> 1. If you're hosting gadgets on gadgets.site.com, you should make absolutely
> sure that any "important" (however you define this) cookies are stored only
> on www.site.com, *not* on .site.com. Ideally no cookies should be sent to
> any given gadget render.
>
> 2. Shindig doesn't yet have an OpenSocial JS implementation that uses the
> RESTful APIs. You're welcome to implement and contribute one though :)
>
> 3. I'm not 100% clear on what you mean by where you're supposed to set
> VIEWER and OWNER. These are passed in as hash-params to the gadget IFRAME,
> for instance. Is that what you mean?
>
> John
>
> On Wed, Apr 30, 2008 at 1:21 PM, Jason Burgess <ja...@holostek.net> wrote:
>
>> Now that I've got a working gadget server and some basic functionality. I
>> seem to be getting lost in the documentation for connecting my site's data
>> to it.
>>
>>
>>
>> Here's what I *think* is going to work based on what I've read. Please
>> correct me where I'm wrong. And there are still a few pieces of the puzzle
>> I'm missing, but I'll point them out along the way.
>>
>>
>>
>> I've got a main website, www.site.com, and a gadgets server,
>> gadgets.site.com.
>>
>>
>>
>> On gadgets.site.com, /gadgets is transparently proxied to the jetty
>> server,
>> while /social is transparently proxied back to www.site.com/social, so
>> that
>> gadgets.site.com believes it is coming from the same server.
>>
>>
>>
>> On /social/data, I'm implementing the RESTful API to retrieve data from the
>> main website's database.
>>
>>
>>
>> From what I understood, shindig will mediate between the RESTful API and
>> the
>> gadgets, but most of that isn't finished yet.
>>
>>
>>
>> From www.site.com, I'm implementing the container to call gadgets.site.com
>> to render the gadgets.
>>
>>
>>
>> One thing I'm still having trouble discerning is where in the container I'm
>> supposed to be setting VIEWER and OWNER.
>>
>>
>>
>> Hopefully, I'm at least headed in the right direction here.
>>
>>
>>
>> Jason
>>
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Questions about implementing shindig
Posted by John Hjelmstad <fa...@google.com>.
Hi Jason:
First off, it sounds like you're on the right track to me. A few notes:
1. If you're hosting gadgets on gadgets.site.com, you should make absolutely
sure that any "important" (however you define this) cookies are stored only
on www.site.com, *not* on .site.com. Ideally no cookies should be sent to
any given gadget render.
2. Shindig doesn't yet have an OpenSocial JS implementation that uses the
RESTful APIs. You're welcome to implement and contribute one though :)
3. I'm not 100% clear on what you mean by where you're supposed to set
VIEWER and OWNER. These are passed in as hash-params to the gadget IFRAME,
for instance. Is that what you mean?
John
On Wed, Apr 30, 2008 at 1:21 PM, Jason Burgess <ja...@holostek.net> wrote:
> Now that I've got a working gadget server and some basic functionality. I
> seem to be getting lost in the documentation for connecting my site's data
> to it.
>
>
>
> Here's what I *think* is going to work based on what I've read. Please
> correct me where I'm wrong. And there are still a few pieces of the puzzle
> I'm missing, but I'll point them out along the way.
>
>
>
> I've got a main website, www.site.com, and a gadgets server,
> gadgets.site.com.
>
>
>
> On gadgets.site.com, /gadgets is transparently proxied to the jetty
> server,
> while /social is transparently proxied back to www.site.com/social, so
> that
> gadgets.site.com believes it is coming from the same server.
>
>
>
> On /social/data, I'm implementing the RESTful API to retrieve data from the
> main website's database.
>
>
>
> From what I understood, shindig will mediate between the RESTful API and
> the
> gadgets, but most of that isn't finished yet.
>
>
>
> From www.site.com, I'm implementing the container to call gadgets.site.com
> to render the gadgets.
>
>
>
> One thing I'm still having trouble discerning is where in the container I'm
> supposed to be setting VIEWER and OWNER.
>
>
>
> Hopefully, I'm at least headed in the right direction here.
>
>
>
> Jason
>
>