On Tue, May 20, 2008 at 11:37 PM, Lini H - Clarion, India < [EMAIL PROTECTED]> 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 > > [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. > >
