You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Chris Chabot <ch...@xs4all.nl> on 2008/05/08 15:17:26 UTC
PHP Shindig & Partuza
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 <ch...@xs4all.nl> 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
>>>
>>>>
>>
Re: PHP Shindig & Partuza
Posted by Colin Alworth <co...@sss-research.com>.
snip
On Wed, May 21, 2008 at 3:28 PM, Kevin Brown <et...@google.com> wrote:
> so there's really no need for the container to pull in
> anything else unless you're writing your own proprietary features. This is
> completely intentional.
>
>
You win the prize - we used to have a set of features for an old container
that we built, but the project has been resurected, and one of my last major
issues is how to cleanly pull in lots of container/gadget javascript...
The metadata stuff works, except that it's a lot of data, and several
requests. Similarly, I could just read through the xml for the gadget (since
I have the url that would normally be passed into the metadata call), and
grab up all the features that way...
Colin
--
Colin Alworth
Software Engineer, SSS Research, Inc.
218.348.4347
colin.alworth@sss-research.com
Re: PHP Shindig & Partuza
Posted by Kevin Brown <et...@google.com>.
On Wed, May 21, 2008 at 11:33 AM, Colin Alworth <
colin.alworth@sss-research.com> wrote:
> Sorry to jump in the middle of a discussion here, but I am also trying to
> generate a container. The samples provided are html, and so all have the
> container feature dependencies setup already, but what if the page (and so
> its gadgets) is dynamic -- how does one discover which javascript requests
> will need to be made for a given set of gadgets?
>
> I see that it is possible to make a request to /gadgets/js/* to get the
> combined js files, and that by setting c=1, the features selected will be
> specific to the container, and not for the gadgets, so
> /gadgets/js/rpc.js?c=1 gets the rpc feature (and its dependencies) from the
> server for the container. Is there a straightforward way to determine the
> set of features required for a given set of gadgets, and thus to phrase the
> javascript request as a single call? Were a single call made per gadget,
> some of the basic javascript would end up getting downloaded and run
> several
> times.
See trunk/javascript/container/sample-metadata.html
It should be noted, however, that currently *only* the rpc feature requires
container-side code, so there's really no need for the container to pull in
anything else unless you're writing your own proprietary features. This is
completely intentional.
>
> I have been playing with this project for about a week, and most details
> seem rather self explanatory (given enough time) -- this one still is
> eluding me. Thanks for any suggestions that can be provided.
>
> Colin Alworth
>
> On Wed, May 21, 2008 at 1:22 PM, Kevin Brown <et...@google.com> wrote:
>
> > On Tue, May 20, 2008 at 11:37 PM, Lini H - Clarion, India <
> > lini.haridas@clariontechnologies.co.in> wrote:
> >
> > > Hi chris
> > >
> > > I m still a bit confused between the gadget server and the container.
> The
> > > gadget server is required to render the html for the application. Now
> > when
> > > does the container exactly comes into the picture?
> >
> >
> > The term "container" generally refers to the website that is showing the
> > gadgets. The gadget server is usually considered a part of the container.
> >
> >
> > >
> > >
> > > Hope to get a quick reply.
> > >
> > > 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: "Eiji Kitamura" <ag...@gmail.com>
> > > Cc: <sh...@incubator.apache.org>
> > > Sent: Thursday, May 08, 2008 6:47 PM
> > > Subject: PHP Shindig & Partuza
> > >
> > >
> > > > 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 <ch...@xs4all.nl> 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
> > > >>>>
> > > >>>>>
> > > >>>
> > > >
> > > >
> > > > --
> > > > 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.
> > >
> > >
> >
>
>
>
> --
> Colin Alworth
> Software Engineer, SSS Research, Inc.
> 218.348.4347
> colin.alworth@sss-research.com
>
Re: PHP Shindig & Partuza
Posted by Chris Chabot <ch...@xs4all.nl>.
Hey Colin,
I've been playing with seperating out javascript files too a little
while ago, and so far my conclusion is that in most cases, it's not
worth it.
Problem becomes that not all of the opensocial/gadgets namespace is
available right away (which they are when the JS is inline), so the
onload handlers can't really run before the document's onload is
fired ... which creates latency, etc.
I have added a 'compress_javascript' key to the config, and if set to
true it will jsmin the features javascripts, which cuts down the size
of it to a manageable amount (50-80k per gadget average).
ps there's also some sample container php code to play with if you
want: http://www.chabotc.com/partuza/
-- Chris
On May 21, 2008, at 8:33 PM, Colin Alworth wrote:
> Sorry to jump in the middle of a discussion here, but I am also
> trying to
> generate a container. The samples provided are html, and so all have
> the
> container feature dependencies setup already, but what if the page
> (and so
> its gadgets) is dynamic -- how does one discover which javascript
> requests
> will need to be made for a given set of gadgets?
>
> I see that it is possible to make a request to /gadgets/js/* to get
> the
> combined js files, and that by setting c=1, the features selected
> will be
> specific to the container, and not for the gadgets, so
> /gadgets/js/rpc.js?c=1 gets the rpc feature (and its dependencies)
> from the
> server for the container. Is there a straightforward way to
> determine the
> set of features required for a given set of gadgets, and thus to
> phrase the
> javascript request as a single call? Were a single call made per
> gadget,
> some of the basic javascript would end up getting downloaded and run
> several
> times.
>
> I have been playing with this project for about a week, and most
> details
> seem rather self explanatory (given enough time) -- this one still is
> eluding me. Thanks for any suggestions that can be provided.
>
> Colin Alworth
>
> On Wed, May 21, 2008 at 1:22 PM, Kevin Brown <et...@google.com> wrote:
>
>> On Tue, May 20, 2008 at 11:37 PM, Lini H - Clarion, India <
>> lini.haridas@clariontechnologies.co.in> wrote:
>>
>>> Hi chris
>>>
>>> I m still a bit confused between the gadget server and the
>>> container. The
>>> gadget server is required to render the html for the application.
>>> Now
>> when
>>> does the container exactly comes into the picture?
>>
>>
>> The term "container" generally refers to the website that is
>> showing the
>> gadgets. The gadget server is usually considered a part of the
>> container.
>>
>>
>>>
>>>
>>> Hope to get a quick reply.
>>>
>>> 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: "Eiji Kitamura" <ag...@gmail.com>
>>> Cc: <sh...@incubator.apache.org>
>>> Sent: Thursday, May 08, 2008 6:47 PM
>>> Subject: PHP Shindig & Partuza
>>>
>>>
>>>> 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 <ch...@xs4all.nl> 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
>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> 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.
>>>
>>>
>>
>
>
>
> --
> Colin Alworth
> Software Engineer, SSS Research, Inc.
> 218.348.4347
> colin.alworth@sss-research.com
Re: PHP Shindig & Partuza
Posted by Colin Alworth <co...@sss-research.com>.
Sorry to jump in the middle of a discussion here, but I am also trying to
generate a container. The samples provided are html, and so all have the
container feature dependencies setup already, but what if the page (and so
its gadgets) is dynamic -- how does one discover which javascript requests
will need to be made for a given set of gadgets?
I see that it is possible to make a request to /gadgets/js/* to get the
combined js files, and that by setting c=1, the features selected will be
specific to the container, and not for the gadgets, so
/gadgets/js/rpc.js?c=1 gets the rpc feature (and its dependencies) from the
server for the container. Is there a straightforward way to determine the
set of features required for a given set of gadgets, and thus to phrase the
javascript request as a single call? Were a single call made per gadget,
some of the basic javascript would end up getting downloaded and run several
times.
I have been playing with this project for about a week, and most details
seem rather self explanatory (given enough time) -- this one still is
eluding me. Thanks for any suggestions that can be provided.
Colin Alworth
On Wed, May 21, 2008 at 1:22 PM, Kevin Brown <et...@google.com> wrote:
> On Tue, May 20, 2008 at 11:37 PM, Lini H - Clarion, India <
> lini.haridas@clariontechnologies.co.in> wrote:
>
> > Hi chris
> >
> > I m still a bit confused between the gadget server and the container. The
> > gadget server is required to render the html for the application. Now
> when
> > does the container exactly comes into the picture?
>
>
> The term "container" generally refers to the website that is showing the
> gadgets. The gadget server is usually considered a part of the container.
>
>
> >
> >
> > Hope to get a quick reply.
> >
> > 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: "Eiji Kitamura" <ag...@gmail.com>
> > Cc: <sh...@incubator.apache.org>
> > Sent: Thursday, May 08, 2008 6:47 PM
> > Subject: PHP Shindig & Partuza
> >
> >
> > > 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 <ch...@xs4all.nl> 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
> > >>>>
> > >>>>>
> > >>>
> > >
> > >
> > > --
> > > 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.
> >
> >
>
--
Colin Alworth
Software Engineer, SSS Research, Inc.
218.348.4347
colin.alworth@sss-research.com
Re: PHP Shindig & Partuza
Posted by Kevin Brown <et...@google.com>.
On Tue, May 20, 2008 at 11:37 PM, Lini H - Clarion, India <
lini.haridas@clariontechnologies.co.in> wrote:
> Hi chris
>
> I m still a bit confused between the gadget server and the container. The
> gadget server is required to render the html for the application. Now when
> does the container exactly comes into the picture?
The term "container" generally refers to the website that is showing the
gadgets. The gadget server is usually considered a part of the container.
>
>
> Hope to get a quick reply.
>
> 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: "Eiji Kitamura" <ag...@gmail.com>
> Cc: <sh...@incubator.apache.org>
> Sent: Thursday, May 08, 2008 6:47 PM
> Subject: PHP Shindig & Partuza
>
>
> > 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 <ch...@xs4all.nl> 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
> >>>>
> >>>>>
> >>>
> >
> >
> > --
> > 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: PHP Shindig & Partuza
Posted by "Lini H - Clarion, India" <li...@clariontechnologies.co.in>.
Hi chris
I m still a bit confused between the gadget server and the container. The gadget server is required to render the html for the application. Now when does the container exactly comes into the picture?
Hope to get a quick reply.
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: "Eiji Kitamura" <ag...@gmail.com>
Cc: <sh...@incubator.apache.org>
Sent: Thursday, May 08, 2008 6:47 PM
Subject: PHP Shindig & Partuza
> 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 <ch...@xs4all.nl> 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
>>>>
>>>>>
>>>
>
>
> --
> 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.