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 <[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]
