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
[EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
To: "Eiji Kitamura" <[EMAIL PROTECTED]>
Cc: <[email protected]>
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 <[EMAIL PROTECTED]> wrote:
>>
>>> ps i have a live version of it here:
>>>
>>> http://partuza.chabotc.com/
>>>
>>> you can register there, add a gadget to your profile (OpenSocial
>>> 0.7 Compliance Tests is my favorite :) and watch it in action.
>>>
>>> The most interesting bit for you is probably patruza/Application/
>>> Views/applications/gadget.php .. this creates the secure token,
>>> parses user prefs on command line and creates a gadget iframe.
>>>
>>> Hope it's of some help
>>>
>>> -- Chris
>>>
>>> On May 3, 2008, at 6:47 PM, Chris Chabot wrote:
>>>
>>>>
>>>> On May 3, 2008, at 6:11 PM, Eiji Kitamura wrote:
>>>>
>>>>> I'm still reading your code to get it work on our SNS site.
>>>>
>>>> I 'm working on the side on a demo SNS site implementation:
>>>> http://code.google.com/p/partuza/
>>>>
>>>> Maybe there's a few things in there that can help on how to use
>>>> shindig. (It's not done yet, but usable enough for an example i
>>>> hope)
>>>>
>>>>> 1. I've found a bug in your code.
>>>>>
>>>>> http://svn.apache.org/repos/asf/incubator/shindig/trunk/php/src/gadgets/ContainerConfig.php
>>>>>
>>>>> you forgot "php" on line 1.
>>>>> <?
>>>>> needs to be
>>>>> <?php
>>>>>
>>>>
>>>> Nice catch, locally i have short tags enabled so i never noticed,
>>>> thanks
>>>>
>>>>> 2. in proxy handler
>>>>>
>>>>> http://svn.apache.org/repos/asf/incubator/shindig/trunk/php/src/gadgets/ProxyHandler.php
>>>>>
>>>>> you "echo"es result in above code but, I prefer it to be in
>>>>> ProxyServlet.php in terms of role servlet.
>>>>> What do you think?
>>>>
>>>> I'm not sure about this one. Normally i would agreed completely
>>>> but the handler already outputs so much (headers etc) from what
>>>> it's proxy'ing that a clean separation between handling &
>>>> outputting would take a lot more then just a return $value type
>>>> thing. I'll keep it in mind and think it over though
>>>>
>>>>> 3. you put all $config into Config::get().
>>>>> I think it's very good idea since "$config" is very common name
>>>>> that when i try to import your code into our framework, name
>>>>> corruption happened.
>>>>> But you forgot to do it in the code below.
>>>>>
>>>>> http://svn.apache.org/repos/asf/incubator/shindig/trunk/php/src/gadgets/samplecontainer/BasicRemoteContent.php
>>>>>
>>>>> I think this is the only one.
>>>>>
>>>>
>>>> Again, good catch :) Fixed in the next commit.
>>>>
>>>>> I'm worrying if you mind me pointing out bugs this way. Tell me
>>>>> if I'm annoying you.
>>>>>
>>>>
>>>> Not at all, I'm grateful you take the time to report them so i can
>>>> fix them!
>>>>
>>>>> By the way, like you had Queens day, we have holidays now, here
>>>>> in Japan. It's called Golden Week. Holidays in a row like one
>>>>> week :)
>>>>>
>>>>
>>>> Lucky you a whole week, was only a day here :-) Happy holidays then!
>>>>
>>>> -- Chris
>>>>
>>>>>
>>>
>
>
> --
> 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.
