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 <[EMAIL PROTECTED]> wrote: > 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. > > > > > -- Colin Alworth Software Engineer, SSS Research, Inc. 218.348.4347 [EMAIL PROTECTED]
