Writeup on my first steps with Shindig (and how to repeat them).

[Reinoud Elhorst <cl...@claude.nl>]

I decided to write down some of my experiences and steps with Shindig, it
might be useful for others wanting to play a bit.

>From the more experienced Shinduggers, I would appreciate feedback on any
mistakes in the document (not that I want to make it my dayjob keeping
the document correct and up to date :) )

http://trac.hyves-api.nl/hyves-api/wiki/ShindigStarted

Re: Writeup on my first steps with Shindig (and how to repeat them).

[Kevin Brown <et...@google.com>]

On Feb 1, 2008 7:48 AM, Brian Eaton <be...@google.com> wrote:

> > "In my opinion (although I'm not sure that everyone on the Shindig list
> > > agrees with me), there should not be a requirement that your container
> and
> > > the Shindig server are in the same language, or share code, share
> > > datasources, share anything but a handful of shared secrets. The only
> thing
> > > that you need in your own programming language is the GadgetSigner
> (soon to
> > > be renamed GadgetTokenSigner) and appropriate subclasses. This is not
> more
> > > than a couple of lines of code in most cases. (I think they can even
> be
> > > compiled to standalone Java programs, which are then run from the
> > > commandline, so they can be called from any environment)."
>
> This is a noble goal, but is it realistic?  There's a lot of per-user
> data the container will have that the gadget needs to peek at: owner
> ids, viewer ids, friends lists, OAuth access tokens.
>
> If we do want to export this information to gadgets the security token
> is going to get quite large.  Or do you imagine a flow where the
> gadget calls back to the parent page to fetch what it needs, then
> forwards that info to the gadget server?


This data doesn't ever go into the security token -- the security token is
used to retrieve it. Most security token generation schemes will involve
encoding a user id or session id or something which is used to look up data
on demand by some back end. The security token should contain as little data
as possible.

Re: Writeup on my first steps with Shindig (and how to repeat them).

[Brian Eaton <be...@google.com>]

> "In my opinion (although I'm not sure that everyone on the Shindig list
> > agrees with me), there should not be a requirement that your container and
> > the Shindig server are in the same language, or share code, share
> > datasources, share anything but a handful of shared secrets. The only thing
> > that you need in your own programming language is the GadgetSigner (soon to
> > be renamed GadgetTokenSigner) and appropriate subclasses. This is not more
> > than a couple of lines of code in most cases. (I think they can even be
> > compiled to standalone Java programs, which are then run from the
> > commandline, so they can be called from any environment)."

This is a noble goal, but is it realistic?  There's a lot of per-user
data the container will have that the gadget needs to peek at: owner
ids, viewer ids, friends lists, OAuth access tokens.

If we do want to export this information to gadgets the security token
is going to get quite large.  Or do you imagine a flow where the
gadget calls back to the parent page to fetch what it needs, then
forwards that info to the gadget server?

Cheers,
Brian

Re: Writeup on my first steps with Shindig (and how to repeat them).

[Reinoud Elhorst <cl...@claude.nl>]

Thanks!

I updated the guide to reflect your comments.

On 2/1/08, Bruno Bowden <br...@google.com> wrote:
>
> Great writeup Reinoud. This is why we need the confluence wiki up and
> running.
>
> Funny definition ;-)
> *   Shindig: (noun) archaic word for brawl
> *
> *   Container-page** The parent-page that hosts the iframes that contain
> the
> gadgets. (note that the OpenSocial spec never defines that gadgets need to
> be hosted in iframes; perhaps more accurate would be to say: the parent
> page
> that hosts the gadgets).*
> Once Caja matures, containers can look at dropping the iframe and inlining
> the gadget. So not only is an iframe not required but it's intentional on
> our part to eliminate the need for it in the future. This allows easier
> communication with container and in some circumstances faster loading of
> pages.
> As for the open issues. You might as well link to the JIRA issues, or
> create
> them if they don't exist. That way readers can easily check on the current
> status of the implementation.
>
>
> On Jan 31, 2008 6:23 PM, Kevin Brown <et...@google.com> wrote:
>
> > Nice writeup. I'll toss out some comments on things that stood out to
> me.
> >
> > "In my opinion (although I'm not sure that everyone on the Shindig list
> > > agrees with me), there should not be a requirement that your container
> > and
> > > the Shindig server are in the same language, or share code, share
> > > datasources, share anything but a handful of shared secrets. The only
> > thing
> > > that you need in your own programming language is the GadgetSigner
> (soon
> > to
> > > be renamed GadgetTokenSigner) and appropriate subclasses. This is not
> > more
> > > than a couple of lines of code in most cases. (I think they can even
> be
> > > compiled to standalone Java programs, which are then run from the
> > > commandline, so they can be called from any environment)."
> > >
> >
> > Personally, I'd strongly encourage this behavior. This will be even
> easier
> > to do when we have a JsonRpc service for grabbing meta data, because you
> > could then use the java shindig regardless of what language your server
> > code
> > uses (i.e. anybody could use it). It would be slightly faster to just
> use
> > the native language directly, but when you factor in things like Caja
> and
> > other libraries, it seems to make more and more sense to just use the
> java
> > server for shindig, and talk to it via the RPC mechanism.
> >
> > "No. Not unless you accept some serious security and other issues. I
> > > wouldn't even call it ready for your own OpenSocial public beta-test.
> > That
> > > being said, Shindig is being developed at an incredible pace, and I
> > wouldn't
> > > be surprised if it *is* production ready by the time you read this."
> >
> >
> > You might want to add any special things you did yourself to get it
> > production ready here -- the fact that there's no "opensocial-0.6" or "
> > opensocial-0.7" in the features/ directory seems like an obvious place
> > where
> > other people might be scratching their heads! The only major security
> > issues
> > that are outsanding right now are locked domain support and the need to
> > implement GadgetSigner. I see them at the bottom of the page -- perhaps
> > just
> > link to them from here?
> >
> > I didn't quite read every detail (busy right now), but I think this is
> > something that will be tremendously helpful to other people.
> >
> > Great job!
> >
> > ~Kevin
> >
> > On Jan 31, 2008 5:50 PM, Reinoud Elhorst <cl...@claude.nl> wrote:
> >
> > > I decided to write down some of my experiences and steps with Shindig,
> > it
> > > might be useful for others wanting to play a bit.
> > >
> > > From the more experienced Shinduggers, I would appreciate feedback on
> > any
> > > mistakes in the document (not that I want to make it my dayjob keeping
> > > the document correct and up to date :) )
> > >
> > > http://trac.hyves-api.nl/hyves-api/wiki/ShindigStarted
> > >
> >
>

Re: Writeup on my first steps with Shindig (and how to repeat them).

[Bruno Bowden <br...@google.com>]

Great writeup Reinoud. This is why we need the confluence wiki up and
running.

Funny definition ;-)
*   Shindig: (noun) archaic word for brawl
*
*   Container-page** The parent-page that hosts the iframes that contain the
gadgets. (note that the OpenSocial spec never defines that gadgets need to
be hosted in iframes; perhaps more accurate would be to say: the parent page
that hosts the gadgets).*
Once Caja matures, containers can look at dropping the iframe and inlining
the gadget. So not only is an iframe not required but it's intentional on
our part to eliminate the need for it in the future. This allows easier
communication with container and in some circumstances faster loading of
pages.
As for the open issues. You might as well link to the JIRA issues, or create
them if they don't exist. That way readers can easily check on the current
status of the implementation.


On Jan 31, 2008 6:23 PM, Kevin Brown <et...@google.com> wrote:

> Nice writeup. I'll toss out some comments on things that stood out to me.
>
> "In my opinion (although I'm not sure that everyone on the Shindig list
> > agrees with me), there should not be a requirement that your container
> and
> > the Shindig server are in the same language, or share code, share
> > datasources, share anything but a handful of shared secrets. The only
> thing
> > that you need in your own programming language is the GadgetSigner (soon
> to
> > be renamed GadgetTokenSigner) and appropriate subclasses. This is not
> more
> > than a couple of lines of code in most cases. (I think they can even be
> > compiled to standalone Java programs, which are then run from the
> > commandline, so they can be called from any environment)."
> >
>
> Personally, I'd strongly encourage this behavior. This will be even easier
> to do when we have a JsonRpc service for grabbing meta data, because you
> could then use the java shindig regardless of what language your server
> code
> uses (i.e. anybody could use it). It would be slightly faster to just use
> the native language directly, but when you factor in things like Caja and
> other libraries, it seems to make more and more sense to just use the java
> server for shindig, and talk to it via the RPC mechanism.
>
> "No. Not unless you accept some serious security and other issues. I
> > wouldn't even call it ready for your own OpenSocial public beta-test.
> That
> > being said, Shindig is being developed at an incredible pace, and I
> wouldn't
> > be surprised if it *is* production ready by the time you read this."
>
>
> You might want to add any special things you did yourself to get it
> production ready here -- the fact that there's no "opensocial-0.6" or "
> opensocial-0.7" in the features/ directory seems like an obvious place
> where
> other people might be scratching their heads! The only major security
> issues
> that are outsanding right now are locked domain support and the need to
> implement GadgetSigner. I see them at the bottom of the page -- perhaps
> just
> link to them from here?
>
> I didn't quite read every detail (busy right now), but I think this is
> something that will be tremendously helpful to other people.
>
> Great job!
>
> ~Kevin
>
> On Jan 31, 2008 5:50 PM, Reinoud Elhorst <cl...@claude.nl> wrote:
>
> > I decided to write down some of my experiences and steps with Shindig,
> it
> > might be useful for others wanting to play a bit.
> >
> > From the more experienced Shinduggers, I would appreciate feedback on
> any
> > mistakes in the document (not that I want to make it my dayjob keeping
> > the document correct and up to date :) )
> >
> > http://trac.hyves-api.nl/hyves-api/wiki/ShindigStarted
> >
>

Re: Writeup on my first steps with Shindig (and how to repeat them).

[Kevin Brown <et...@google.com>]

Nice writeup. I'll toss out some comments on things that stood out to me.

"In my opinion (although I'm not sure that everyone on the Shindig list
> agrees with me), there should not be a requirement that your container and
> the Shindig server are in the same language, or share code, share
> datasources, share anything but a handful of shared secrets. The only thing
> that you need in your own programming language is the GadgetSigner (soon to
> be renamed GadgetTokenSigner) and appropriate subclasses. This is not more
> than a couple of lines of code in most cases. (I think they can even be
> compiled to standalone Java programs, which are then run from the
> commandline, so they can be called from any environment)."
>

Personally, I'd strongly encourage this behavior. This will be even easier
to do when we have a JsonRpc service for grabbing meta data, because you
could then use the java shindig regardless of what language your server code
uses (i.e. anybody could use it). It would be slightly faster to just use
the native language directly, but when you factor in things like Caja and
other libraries, it seems to make more and more sense to just use the java
server for shindig, and talk to it via the RPC mechanism.

"No. Not unless you accept some serious security and other issues. I
> wouldn't even call it ready for your own OpenSocial public beta-test. That
> being said, Shindig is being developed at an incredible pace, and I wouldn't
> be surprised if it *is* production ready by the time you read this."


You might want to add any special things you did yourself to get it
production ready here -- the fact that there's no "opensocial-0.6" or "
opensocial-0.7" in the features/ directory seems like an obvious place where
other people might be scratching their heads! The only major security issues
that are outsanding right now are locked domain support and the need to
implement GadgetSigner. I see them at the bottom of the page -- perhaps just
link to them from here?

I didn't quite read every detail (busy right now), but I think this is
something that will be tremendously helpful to other people.

Great job!

~Kevin

On Jan 31, 2008 5:50 PM, Reinoud Elhorst <cl...@claude.nl> wrote:

> I decided to write down some of my experiences and steps with Shindig, it
> might be useful for others wanting to play a bit.
>
> From the more experienced Shinduggers, I would appreciate feedback on any
> mistakes in the document (not that I want to make it my dayjob keeping
> the document correct and up to date :) )
>
> http://trac.hyves-api.nl/hyves-api/wiki/ShindigStarted
>