You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Arne Roomann-Kurrik <ku...@google.com> on 2008/03/07 01:07:28 UTC
Relative paths in config/syndicator.js
I'm trying to put together a demo of shindig where I download the source
from SVN, build and run the server, and display a gadget in the OpenSocial
sample container - hopefully under 10 minutes. Since I've been playing
around with the sample container, I've noticed that calls to rpc_relay.html
are being directed to
http://<my_server>:8080/gadgets/gadgets/files/container/rpc_relay.html#..................
(note the double gadgets path) which results in a 404. I poked around a bit
and found that the "parentRelayUrl" configuration property in
/config/syndicator.js is relatively pathed - prefixing a "/" provides the
correct response (an "Unknown RPC service" error, but that's expected).
Is there a reason for the relative path in the configuration file? I
understand that this is just for testing and will be changed in a production
setting, but changing it in the source will make the "out of box" experience
a bit smoother, IMO.
Thanks,
~Arne
Re: Relative paths in config/syndicator.js
Posted by Kevin Brown <et...@google.com>.
Working on it now.
On Mon, Mar 10, 2008 at 2:58 PM, Cassie <do...@apache.org> wrote:
> awesome, so if you check this in then magically everything will be happy!
> hope you get that large thing in soon...
>
>
> On Mon, Mar 10, 2008 at 9:54 PM, Arne Roomann-Kurrik <ku...@google.com>
> wrote:
>
> > Great, thanks for including that!
> >
> > ~Arne
> >
> >
> > On Mon, Mar 10, 2008 at 12:31 PM, Kevin Brown <et...@google.com> wrote:
> >
> > > In my big patch (SHINDIG-118 I think) I've come up with what I think
> is
> > a
> > > solution that works:
> > >
> > > - gadgets.js always sets parent = http://<document.location.host>
> > > - default syndicator is set to /gadgets/...
> > >
> > > This allows everything to work fine "out of the box", and even on
> > > arbitrary
> > > domains as long as the /gadgets/ context path is consistent. If you
> > change
> > > this, you have to modify your syndicator config.
> > >
> > > verified this on all sample pages + samplecontainer and it seemed to
> > work.
> > >
> > > On Mon, Mar 10, 2008 at 11:06 AM, Arne Roomann-Kurrik <
> kurrik@google.com
> > >
> > > wrote:
> > >
> > > > I've been getting the same problem when viewing my demo in the
> > > > samplecontainer, so I've just been using the /gadgets/ifr url to
> show
> > > the
> > > > gadget rendering full-screen. (Force-reload isn't working for me
> > > either).
> > > >
> > > > I haven't tested Chris' workaround since the demo (this afternoon)
> is
> > > > going
> > > > to be downloading shindig from svn and building it, I don't want to
> > get
> > > > people confused by applying my own patches to the source during the
> > > demo.
> > > > That being said, I can play around with things a bit later today -
> > > Chris,
> > > > if
> > > > you post your patch again (I guess in JIRA?) I'll see if it fixes
> the
> > > > problem I'm seeing.
> > > >
> > > > ~Arne
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Mar 10, 2008 at 10:39 AM, Cassie <do...@apache.org> wrote:
> > > >
> > > > > Hmm... so force-reloading wasn't working for my java based
> > container.
> > > > > And also, your attached diff unfortunately didn't make it through.
> > > > >
> > > > > Perhaps this is just a me-only problem, has anybody else gotten
> this
> > > to
> > > > > work?
> > > > > Thanks.
> > > > >
> > > > > - Cassie
> > > > >
> > > > >
> > > > > On Sun, Mar 9, 2008 at 4:37 PM, Chris Chabot <ch...@xs4all.nl>
> > > wrote:
> > > > >
> > > > > > I've been able to confirm this by adding a &time=<time in ms> to
> > the
> > > > > > IFRAME src tag (in the javascript/container/gadgets.js
> > > > > > gadgets.IfrGadget.prototype.getIframeUrl function)
> > > > > >
> > > > > > I've attached a diff for what works for me here locally. It's
> > > probably
> > > > > not
> > > > > > the right way to fix it but something of a work-around, but at
> > least
> > > > > with
> > > > > > this the samples are working correctly for me :)
> > > > > >
> > > > > > Oh ps, sample7.html wasn't working for me either while for
> > instance
> > > > > > sample2.html was (both with a config that included a
> > > > /gadgets/files/...
> > > > > > parentRelayUr), it turns out the difference between the two is
> > that
> > > > > sample7
> > > > > > includes:
> > > > > >
> > > > > > gadgets.container.setParentUrl("http://" +
> > > > document.location.host+
> > > > > > '/');
> > > > > >
> > > > > > And hence the final url was http://myhost//gadgets/... (notice
> the
> > > > > double
> > > > > > /, which made the (php-) server break), by removing this line
> > > > everything
> > > > > > worked as it was supposed to again.
> > > > > >
> > > > > >
> > > > > > -- Chris
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mar 9, 2008, at 3:38 PM, Chris Chabot wrote:
> > > > > >
> > > > > > I got the same problem here with the sample?.html files:
> "Invalid
> > > > auth
> > > > > > > token", and it might be a PHP shindig only problem i have here
> > > that
> > > > > > > coincidentally gives the same error, but maybe it's not
> > > coincidence
> > > > so
> > > > > i'll
> > > > > > > post what i've found here anyhow :)
> > > > > > >
> > > > > > > Basically what i've found with some console.log'ing is that on
> a
> > > > first
> > > > > > > page load (or forced reload) i get (console.log("auth comp:
> > > > > > > "+authToken[rpc.f]+" = "+rpc.t);)
> > > > > > >
> > > > > > > auth comp: 1185834238 = 1185834238
> > > > > > >
> > > > > > > but when i do a 'soft reload' (so no forced reload) i get:
> > > > > > >
> > > > > > > auth comp: 201272794 = 1185834238
> > > > > > >
> > > > > > > So it's still using the old token from the previous request,
> > hence
> > > > the
> > > > > > > token's aren't identical, and you get an auth token error.
> > > > > > >
> > > > > > > Since the original report said that when Arne changed the URL
> it
> > > > > worked,
> > > > > > > now it might not have been a absolute vs relative URL problem,
> > but
> > > > > just have
> > > > > > > forced the browser to reload the frame's, and hence working
> > again
> > > (a
> > > > > second
> > > > > > > refresh after that would've shown i think that it was still
> > > > 'broken')
> > > > > > >
> > > > > > > -- Chris
> > > > > > >
> > > > > > >
> > > > > > > On Mar 7, 2008, at 9:45 PM, Kevin Brown wrote:
> > > > > > >
> > > > > > >
> > > > > > > > It shouldn't -- auth token validation is based on the iframe
> > id,
> > > > not
> > > > > > > > the
> > > > > > > > url. I'll take a look.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ~Kevin
> > >
> >
>
--
~Kevin
Re: Relative paths in config/syndicator.js
Posted by Cassie <do...@apache.org>.
awesome, so if you check this in then magically everything will be happy!
hope you get that large thing in soon...
On Mon, Mar 10, 2008 at 9:54 PM, Arne Roomann-Kurrik <ku...@google.com>
wrote:
> Great, thanks for including that!
>
> ~Arne
>
>
> On Mon, Mar 10, 2008 at 12:31 PM, Kevin Brown <et...@google.com> wrote:
>
> > In my big patch (SHINDIG-118 I think) I've come up with what I think is
> a
> > solution that works:
> >
> > - gadgets.js always sets parent = http://<document.location.host>
> > - default syndicator is set to /gadgets/...
> >
> > This allows everything to work fine "out of the box", and even on
> > arbitrary
> > domains as long as the /gadgets/ context path is consistent. If you
> change
> > this, you have to modify your syndicator config.
> >
> > verified this on all sample pages + samplecontainer and it seemed to
> work.
> >
> > On Mon, Mar 10, 2008 at 11:06 AM, Arne Roomann-Kurrik <kurrik@google.com
> >
> > wrote:
> >
> > > I've been getting the same problem when viewing my demo in the
> > > samplecontainer, so I've just been using the /gadgets/ifr url to show
> > the
> > > gadget rendering full-screen. (Force-reload isn't working for me
> > either).
> > >
> > > I haven't tested Chris' workaround since the demo (this afternoon) is
> > > going
> > > to be downloading shindig from svn and building it, I don't want to
> get
> > > people confused by applying my own patches to the source during the
> > demo.
> > > That being said, I can play around with things a bit later today -
> > Chris,
> > > if
> > > you post your patch again (I guess in JIRA?) I'll see if it fixes the
> > > problem I'm seeing.
> > >
> > > ~Arne
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Mar 10, 2008 at 10:39 AM, Cassie <do...@apache.org> wrote:
> > >
> > > > Hmm... so force-reloading wasn't working for my java based
> container.
> > > > And also, your attached diff unfortunately didn't make it through.
> > > >
> > > > Perhaps this is just a me-only problem, has anybody else gotten this
> > to
> > > > work?
> > > > Thanks.
> > > >
> > > > - Cassie
> > > >
> > > >
> > > > On Sun, Mar 9, 2008 at 4:37 PM, Chris Chabot <ch...@xs4all.nl>
> > wrote:
> > > >
> > > > > I've been able to confirm this by adding a &time=<time in ms> to
> the
> > > > > IFRAME src tag (in the javascript/container/gadgets.js
> > > > > gadgets.IfrGadget.prototype.getIframeUrl function)
> > > > >
> > > > > I've attached a diff for what works for me here locally. It's
> > probably
> > > > not
> > > > > the right way to fix it but something of a work-around, but at
> least
> > > > with
> > > > > this the samples are working correctly for me :)
> > > > >
> > > > > Oh ps, sample7.html wasn't working for me either while for
> instance
> > > > > sample2.html was (both with a config that included a
> > > /gadgets/files/...
> > > > > parentRelayUr), it turns out the difference between the two is
> that
> > > > sample7
> > > > > includes:
> > > > >
> > > > > gadgets.container.setParentUrl("http://" +
> > > document.location.host+
> > > > > '/');
> > > > >
> > > > > And hence the final url was http://myhost//gadgets/... (notice the
> > > > double
> > > > > /, which made the (php-) server break), by removing this line
> > > everything
> > > > > worked as it was supposed to again.
> > > > >
> > > > >
> > > > > -- Chris
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mar 9, 2008, at 3:38 PM, Chris Chabot wrote:
> > > > >
> > > > > I got the same problem here with the sample?.html files: "Invalid
> > > auth
> > > > > > token", and it might be a PHP shindig only problem i have here
> > that
> > > > > > coincidentally gives the same error, but maybe it's not
> > coincidence
> > > so
> > > > i'll
> > > > > > post what i've found here anyhow :)
> > > > > >
> > > > > > Basically what i've found with some console.log'ing is that on a
> > > first
> > > > > > page load (or forced reload) i get (console.log("auth comp:
> > > > > > "+authToken[rpc.f]+" = "+rpc.t);)
> > > > > >
> > > > > > auth comp: 1185834238 = 1185834238
> > > > > >
> > > > > > but when i do a 'soft reload' (so no forced reload) i get:
> > > > > >
> > > > > > auth comp: 201272794 = 1185834238
> > > > > >
> > > > > > So it's still using the old token from the previous request,
> hence
> > > the
> > > > > > token's aren't identical, and you get an auth token error.
> > > > > >
> > > > > > Since the original report said that when Arne changed the URL it
> > > > worked,
> > > > > > now it might not have been a absolute vs relative URL problem,
> but
> > > > just have
> > > > > > forced the browser to reload the frame's, and hence working
> again
> > (a
> > > > second
> > > > > > refresh after that would've shown i think that it was still
> > > 'broken')
> > > > > >
> > > > > > -- Chris
> > > > > >
> > > > > >
> > > > > > On Mar 7, 2008, at 9:45 PM, Kevin Brown wrote:
> > > > > >
> > > > > >
> > > > > > > It shouldn't -- auth token validation is based on the iframe
> id,
> > > not
> > > > > > > the
> > > > > > > url. I'll take a look.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
>
Re: Relative paths in config/syndicator.js
Posted by Arne Roomann-Kurrik <ku...@google.com>.
Great, thanks for including that!
~Arne
On Mon, Mar 10, 2008 at 12:31 PM, Kevin Brown <et...@google.com> wrote:
> In my big patch (SHINDIG-118 I think) I've come up with what I think is a
> solution that works:
>
> - gadgets.js always sets parent = http://<document.location.host>
> - default syndicator is set to /gadgets/...
>
> This allows everything to work fine "out of the box", and even on
> arbitrary
> domains as long as the /gadgets/ context path is consistent. If you change
> this, you have to modify your syndicator config.
>
> verified this on all sample pages + samplecontainer and it seemed to work.
>
> On Mon, Mar 10, 2008 at 11:06 AM, Arne Roomann-Kurrik <ku...@google.com>
> wrote:
>
> > I've been getting the same problem when viewing my demo in the
> > samplecontainer, so I've just been using the /gadgets/ifr url to show
> the
> > gadget rendering full-screen. (Force-reload isn't working for me
> either).
> >
> > I haven't tested Chris' workaround since the demo (this afternoon) is
> > going
> > to be downloading shindig from svn and building it, I don't want to get
> > people confused by applying my own patches to the source during the
> demo.
> > That being said, I can play around with things a bit later today -
> Chris,
> > if
> > you post your patch again (I guess in JIRA?) I'll see if it fixes the
> > problem I'm seeing.
> >
> > ~Arne
> >
> >
> >
> >
> >
> >
> > On Mon, Mar 10, 2008 at 10:39 AM, Cassie <do...@apache.org> wrote:
> >
> > > Hmm... so force-reloading wasn't working for my java based container.
> > > And also, your attached diff unfortunately didn't make it through.
> > >
> > > Perhaps this is just a me-only problem, has anybody else gotten this
> to
> > > work?
> > > Thanks.
> > >
> > > - Cassie
> > >
> > >
> > > On Sun, Mar 9, 2008 at 4:37 PM, Chris Chabot <ch...@xs4all.nl>
> wrote:
> > >
> > > > I've been able to confirm this by adding a &time=<time in ms> to the
> > > > IFRAME src tag (in the javascript/container/gadgets.js
> > > > gadgets.IfrGadget.prototype.getIframeUrl function)
> > > >
> > > > I've attached a diff for what works for me here locally. It's
> probably
> > > not
> > > > the right way to fix it but something of a work-around, but at least
> > > with
> > > > this the samples are working correctly for me :)
> > > >
> > > > Oh ps, sample7.html wasn't working for me either while for instance
> > > > sample2.html was (both with a config that included a
> > /gadgets/files/...
> > > > parentRelayUr), it turns out the difference between the two is that
> > > sample7
> > > > includes:
> > > >
> > > > gadgets.container.setParentUrl("http://" +
> > document.location.host+
> > > > '/');
> > > >
> > > > And hence the final url was http://myhost//gadgets/... (notice the
> > > double
> > > > /, which made the (php-) server break), by removing this line
> > everything
> > > > worked as it was supposed to again.
> > > >
> > > >
> > > > -- Chris
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mar 9, 2008, at 3:38 PM, Chris Chabot wrote:
> > > >
> > > > I got the same problem here with the sample?.html files: "Invalid
> > auth
> > > > > token", and it might be a PHP shindig only problem i have here
> that
> > > > > coincidentally gives the same error, but maybe it's not
> coincidence
> > so
> > > i'll
> > > > > post what i've found here anyhow :)
> > > > >
> > > > > Basically what i've found with some console.log'ing is that on a
> > first
> > > > > page load (or forced reload) i get (console.log("auth comp:
> > > > > "+authToken[rpc.f]+" = "+rpc.t);)
> > > > >
> > > > > auth comp: 1185834238 = 1185834238
> > > > >
> > > > > but when i do a 'soft reload' (so no forced reload) i get:
> > > > >
> > > > > auth comp: 201272794 = 1185834238
> > > > >
> > > > > So it's still using the old token from the previous request, hence
> > the
> > > > > token's aren't identical, and you get an auth token error.
> > > > >
> > > > > Since the original report said that when Arne changed the URL it
> > > worked,
> > > > > now it might not have been a absolute vs relative URL problem, but
> > > just have
> > > > > forced the browser to reload the frame's, and hence working again
> (a
> > > second
> > > > > refresh after that would've shown i think that it was still
> > 'broken')
> > > > >
> > > > > -- Chris
> > > > >
> > > > >
> > > > > On Mar 7, 2008, at 9:45 PM, Kevin Brown wrote:
> > > > >
> > > > >
> > > > > > It shouldn't -- auth token validation is based on the iframe id,
> > not
> > > > > > the
> > > > > > url. I'll take a look.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > >
> >
>
>
>
> --
> ~Kevin
>
Re: Relative paths in config/syndicator.js
Posted by Kevin Brown <et...@google.com>.
In my big patch (SHINDIG-118 I think) I've come up with what I think is a
solution that works:
- gadgets.js always sets parent = http://<document.location.host>
- default syndicator is set to /gadgets/...
This allows everything to work fine "out of the box", and even on arbitrary
domains as long as the /gadgets/ context path is consistent. If you change
this, you have to modify your syndicator config.
verified this on all sample pages + samplecontainer and it seemed to work.
On Mon, Mar 10, 2008 at 11:06 AM, Arne Roomann-Kurrik <ku...@google.com>
wrote:
> I've been getting the same problem when viewing my demo in the
> samplecontainer, so I've just been using the /gadgets/ifr url to show the
> gadget rendering full-screen. (Force-reload isn't working for me either).
>
> I haven't tested Chris' workaround since the demo (this afternoon) is
> going
> to be downloading shindig from svn and building it, I don't want to get
> people confused by applying my own patches to the source during the demo.
> That being said, I can play around with things a bit later today - Chris,
> if
> you post your patch again (I guess in JIRA?) I'll see if it fixes the
> problem I'm seeing.
>
> ~Arne
>
>
>
>
>
>
> On Mon, Mar 10, 2008 at 10:39 AM, Cassie <do...@apache.org> wrote:
>
> > Hmm... so force-reloading wasn't working for my java based container.
> > And also, your attached diff unfortunately didn't make it through.
> >
> > Perhaps this is just a me-only problem, has anybody else gotten this to
> > work?
> > Thanks.
> >
> > - Cassie
> >
> >
> > On Sun, Mar 9, 2008 at 4:37 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> >
> > > I've been able to confirm this by adding a &time=<time in ms> to the
> > > IFRAME src tag (in the javascript/container/gadgets.js
> > > gadgets.IfrGadget.prototype.getIframeUrl function)
> > >
> > > I've attached a diff for what works for me here locally. It's probably
> > not
> > > the right way to fix it but something of a work-around, but at least
> > with
> > > this the samples are working correctly for me :)
> > >
> > > Oh ps, sample7.html wasn't working for me either while for instance
> > > sample2.html was (both with a config that included a
> /gadgets/files/...
> > > parentRelayUr), it turns out the difference between the two is that
> > sample7
> > > includes:
> > >
> > > gadgets.container.setParentUrl("http://" +
> document.location.host+
> > > '/');
> > >
> > > And hence the final url was http://myhost//gadgets/... (notice the
> > double
> > > /, which made the (php-) server break), by removing this line
> everything
> > > worked as it was supposed to again.
> > >
> > >
> > > -- Chris
> > >
> > >
> > >
> > >
> > >
> > > On Mar 9, 2008, at 3:38 PM, Chris Chabot wrote:
> > >
> > > I got the same problem here with the sample?.html files: "Invalid
> auth
> > > > token", and it might be a PHP shindig only problem i have here that
> > > > coincidentally gives the same error, but maybe it's not coincidence
> so
> > i'll
> > > > post what i've found here anyhow :)
> > > >
> > > > Basically what i've found with some console.log'ing is that on a
> first
> > > > page load (or forced reload) i get (console.log("auth comp:
> > > > "+authToken[rpc.f]+" = "+rpc.t);)
> > > >
> > > > auth comp: 1185834238 = 1185834238
> > > >
> > > > but when i do a 'soft reload' (so no forced reload) i get:
> > > >
> > > > auth comp: 201272794 = 1185834238
> > > >
> > > > So it's still using the old token from the previous request, hence
> the
> > > > token's aren't identical, and you get an auth token error.
> > > >
> > > > Since the original report said that when Arne changed the URL it
> > worked,
> > > > now it might not have been a absolute vs relative URL problem, but
> > just have
> > > > forced the browser to reload the frame's, and hence working again (a
> > second
> > > > refresh after that would've shown i think that it was still
> 'broken')
> > > >
> > > > -- Chris
> > > >
> > > >
> > > > On Mar 7, 2008, at 9:45 PM, Kevin Brown wrote:
> > > >
> > > >
> > > > > It shouldn't -- auth token validation is based on the iframe id,
> not
> > > > > the
> > > > > url. I'll take a look.
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> >
>
--
~Kevin
Re: Relative paths in config/syndicator.js
Posted by Arne Roomann-Kurrik <ku...@google.com>.
I've been getting the same problem when viewing my demo in the
samplecontainer, so I've just been using the /gadgets/ifr url to show the
gadget rendering full-screen. (Force-reload isn't working for me either).
I haven't tested Chris' workaround since the demo (this afternoon) is going
to be downloading shindig from svn and building it, I don't want to get
people confused by applying my own patches to the source during the demo.
That being said, I can play around with things a bit later today - Chris, if
you post your patch again (I guess in JIRA?) I'll see if it fixes the
problem I'm seeing.
~Arne
On Mon, Mar 10, 2008 at 10:39 AM, Cassie <do...@apache.org> wrote:
> Hmm... so force-reloading wasn't working for my java based container.
> And also, your attached diff unfortunately didn't make it through.
>
> Perhaps this is just a me-only problem, has anybody else gotten this to
> work?
> Thanks.
>
> - Cassie
>
>
> On Sun, Mar 9, 2008 at 4:37 PM, Chris Chabot <ch...@xs4all.nl> wrote:
>
> > I've been able to confirm this by adding a &time=<time in ms> to the
> > IFRAME src tag (in the javascript/container/gadgets.js
> > gadgets.IfrGadget.prototype.getIframeUrl function)
> >
> > I've attached a diff for what works for me here locally. It's probably
> not
> > the right way to fix it but something of a work-around, but at least
> with
> > this the samples are working correctly for me :)
> >
> > Oh ps, sample7.html wasn't working for me either while for instance
> > sample2.html was (both with a config that included a /gadgets/files/...
> > parentRelayUr), it turns out the difference between the two is that
> sample7
> > includes:
> >
> > gadgets.container.setParentUrl("http://" + document.location.host+
> > '/');
> >
> > And hence the final url was http://myhost//gadgets/... (notice the
> double
> > /, which made the (php-) server break), by removing this line everything
> > worked as it was supposed to again.
> >
> >
> > -- Chris
> >
> >
> >
> >
> >
> > On Mar 9, 2008, at 3:38 PM, Chris Chabot wrote:
> >
> > I got the same problem here with the sample?.html files: "Invalid auth
> > > token", and it might be a PHP shindig only problem i have here that
> > > coincidentally gives the same error, but maybe it's not coincidence so
> i'll
> > > post what i've found here anyhow :)
> > >
> > > Basically what i've found with some console.log'ing is that on a first
> > > page load (or forced reload) i get (console.log("auth comp:
> > > "+authToken[rpc.f]+" = "+rpc.t);)
> > >
> > > auth comp: 1185834238 = 1185834238
> > >
> > > but when i do a 'soft reload' (so no forced reload) i get:
> > >
> > > auth comp: 201272794 = 1185834238
> > >
> > > So it's still using the old token from the previous request, hence the
> > > token's aren't identical, and you get an auth token error.
> > >
> > > Since the original report said that when Arne changed the URL it
> worked,
> > > now it might not have been a absolute vs relative URL problem, but
> just have
> > > forced the browser to reload the frame's, and hence working again (a
> second
> > > refresh after that would've shown i think that it was still 'broken')
> > >
> > > -- Chris
> > >
> > >
> > > On Mar 7, 2008, at 9:45 PM, Kevin Brown wrote:
> > >
> > >
> > > > It shouldn't -- auth token validation is based on the iframe id, not
> > > > the
> > > > url. I'll take a look.
> > > >
> > > >
> > > >
> > > >
> >
> >
>
Re: Relative paths in config/syndicator.js
Posted by Cassie <do...@apache.org>.
Hmm... so force-reloading wasn't working for my java based container.
And also, your attached diff unfortunately didn't make it through.
Perhaps this is just a me-only problem, has anybody else gotten this to
work?
Thanks.
- Cassie
On Sun, Mar 9, 2008 at 4:37 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> I've been able to confirm this by adding a &time=<time in ms> to the
> IFRAME src tag (in the javascript/container/gadgets.js
> gadgets.IfrGadget.prototype.getIframeUrl function)
>
> I've attached a diff for what works for me here locally. It's probably not
> the right way to fix it but something of a work-around, but at least with
> this the samples are working correctly for me :)
>
> Oh ps, sample7.html wasn't working for me either while for instance
> sample2.html was (both with a config that included a /gadgets/files/...
> parentRelayUr), it turns out the difference between the two is that sample7
> includes:
>
> gadgets.container.setParentUrl("http://" + document.location.host +
> '/');
>
> And hence the final url was http://myhost//gadgets/... (notice the double
> /, which made the (php-) server break), by removing this line everything
> worked as it was supposed to again.
>
>
> -- Chris
>
>
>
>
>
> On Mar 9, 2008, at 3:38 PM, Chris Chabot wrote:
>
> I got the same problem here with the sample?.html files: "Invalid auth
> > token", and it might be a PHP shindig only problem i have here that
> > coincidentally gives the same error, but maybe it's not coincidence so i'll
> > post what i've found here anyhow :)
> >
> > Basically what i've found with some console.log'ing is that on a first
> > page load (or forced reload) i get (console.log("auth comp:
> > "+authToken[rpc.f]+" = "+rpc.t);)
> >
> > auth comp: 1185834238 = 1185834238
> >
> > but when i do a 'soft reload' (so no forced reload) i get:
> >
> > auth comp: 201272794 = 1185834238
> >
> > So it's still using the old token from the previous request, hence the
> > token's aren't identical, and you get an auth token error.
> >
> > Since the original report said that when Arne changed the URL it worked,
> > now it might not have been a absolute vs relative URL problem, but just have
> > forced the browser to reload the frame's, and hence working again (a second
> > refresh after that would've shown i think that it was still 'broken')
> >
> > -- Chris
> >
> >
> > On Mar 7, 2008, at 9:45 PM, Kevin Brown wrote:
> >
> >
> > > It shouldn't -- auth token validation is based on the iframe id, not
> > > the
> > > url. I'll take a look.
> > >
> > >
> > >
> > >
>
>
Re: Relative paths in config/syndicator.js
Posted by Chris Chabot <ch...@xs4all.nl>.
I've been able to confirm this by adding a &time=<time in ms> to the
IFRAME src tag (in the javascript/container/gadgets.js
gadgets.IfrGadget.prototype.getIframeUrl function)
I've attached a diff for what works for me here locally. It's probably
not the right way to fix it but something of a work-around, but at
least with this the samples are working correctly for me :)
Oh ps, sample7.html wasn't working for me either while for instance
sample2.html was (both with a config that included a /gadgets/
files/... parentRelayUr), it turns out the difference between the two
is that sample7 includes:
gadgets.container.setParentUrl("http://" + document.location.host +
'/');
And hence the final url was http://myhost//gadgets/... (notice the
double /, which made the (php-) server break), by removing this line
everything worked as it was supposed to again.
-- Chris
Re: Relative paths in config/syndicator.js
Posted by Chris Chabot <ch...@xs4all.nl>.
I got the same problem here with the sample?.html files: "Invalid auth
token", and it might be a PHP shindig only problem i have here that
coincidentally gives the same error, but maybe it's not coincidence so
i'll post what i've found here anyhow :)
Basically what i've found with some console.log'ing is that on a first
page load (or forced reload) i get (console.log("auth comp:
"+authToken[rpc.f]+" = "+rpc.t);)
auth comp: 1185834238 = 1185834238
but when i do a 'soft reload' (so no forced reload) i get:
auth comp: 201272794 = 1185834238
So it's still using the old token from the previous request, hence the
token's aren't identical, and you get an auth token error.
Since the original report said that when Arne changed the URL it
worked, now it might not have been a absolute vs relative URL problem,
but just have forced the browser to reload the frame's, and hence
working again (a second refresh after that would've shown i think that
it was still 'broken')
-- Chris
On Mar 7, 2008, at 9:45 PM, Kevin Brown wrote:
>
> It shouldn't -- auth token validation is based on the iframe id, not
> the
> url. I'll take a look.
>
>
>
Re: Relative paths in config/syndicator.js
Posted by Kevin Brown <et...@google.com>.
On Fri, Mar 7, 2008 at 6:27 AM, Cassie <do...@apache.org> wrote:
> Arne - When I change the syndicator to use
> /gadgets/files/container/rpc_relay.html as the url, the request goes
> through
> but then I get an "Invalid auth token" javascript error when calling
> something like adjustHeight().
>
> What else did you need to do to get it to work in the samplecontainer?
>
> Or, does anybody know why an invalid auth token error would occur with
> this
> change?
It shouldn't -- auth token validation is based on the iframe id, not the
url. I'll take a look.
>
> I cleaned up the samplecontainer html so that the gadget iframe isn't
> 100%..
> which means I really want dynamic-height to work now :)
>
> This should be reproducable from head with the one char syndicator.js
> change.
>
> - Cassie
>
>
> On Fri, Mar 7, 2008 at 12:33 PM, Kevin Brown <et...@google.com> wrote:
>
> > The default synd should be set up specifically for the sample files --
> > period. If someone is using a different default path (such as a
> production
> > site), they should provide their own syndicator config.
> >
> > On Fri, Mar 7, 2008 at 3:01 AM, Cassie <do...@apache.org> wrote:
> >
> > > Can't we just add some code to rpc.js which will append a slash if the
> > > parent does not end in a slash? Or something similar to that...
> > > If we can't do that then perhaps the samplecontainer should have its
> own
> > > synd file somehow... or maybe in the sample container html init we
> > should
> > > just reset the parentRelayUrl to whatever it needs to be?
> > >
> > > (basically I just don't like changing the docs telling people it won't
> > > work
> > > :)
> > >
> > > - Cassie
> > >
> > >
> > > On Fri, Mar 7, 2008 at 1:31 AM, Arne Roomann-Kurrik <kurrik@google.com
> >
> > > wrote:
> > >
> > > > I figured that this might be the case. Which is preferable then?
> If
> > we
> > > > leave it as-is, I could submit a patch for the sample container docs
> > to
> > > > document the need to change this value.
> > > >
> > > > ~Arne
> > > >
> > > >
> > > > On Thu, Mar 6, 2008 at 4:23 PM, Zhen Wang <wa...@google.com> wrote:
> > > >
> > > > > The default relay URL was changed because it broke some
> > non-opensocial
> > > > > sample containers which pass parent parameters with a trailing
> > slash.
> > > > >
> > > > > On Thu, Mar 6, 2008 at 4:14 PM, Kevin Brown <et...@google.com>
> wrote:
> > > > > > Looks like an oversight. It was previously just
> > files/container/...,
> > > > but
> > > > > > that introduced issues with different parent parameters.
> > > > > >
> > > > > > I think the default value should be /gadgets/files/... so that
> the
> > > > "out
> > > > > of
> > > > > > the box" setup is fine, and it only has to be changed if you
> > change
> > > > your
> > > > > > context path manually.
> > > > > >
> > > > > > Zhen?
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Mar 6, 2008 at 4:07 PM, Arne Roomann-Kurrik <
> > > kurrik@google.com
> > > > >
> > > > > > wrote:
> > > > > > > I'm trying to put together a demo of shindig where I download
> > the
> > > > > source
> > > > > > > from SVN, build and run the server, and display a gadget in
> the
> > > > > OpenSocial
> > > > > > > sample container - hopefully under 10 minutes. Since I've
> been
> > > > > playing
> > > > > > > around with the sample container, I've noticed that calls to
> > > > > > rpc_relay.html
> > > > > > > are being directed to
> > > > > > >
> > > > > > >
> > > > > >
> > > > > http://
> > > >
> > >
> >
> <my_server>:8080/gadgets/gadgets/files/container/rpc_relay.html#..................
> > > > > > >
> > > > > > > (note the double gadgets path) which results in a 404. I
> poked
> > > > around
> > > > > a
> > > > > > bit
> > > > > > > and found that the "parentRelayUrl" configuration property in
> > > > > > > /config/syndicator.js is relatively pathed - prefixing a "/"
> > > > provides
> > > > > the
> > > > > > > correct response (an "Unknown RPC service" error, but that's
> > > > > expected).
> > > > > > >
> > > > > > > Is there a reason for the relative path in the configuration
> > file?
> > > > I
> > > > > > > understand that this is just for testing and will be changed
> in
> > a
> > > > > > production
> > > > > > > setting, but changing it in the source will make the "out of
> > box"
> > > > > > experience
> > > > > > > a bit smoother, IMO.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > ~Arne
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ~Kevin
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
>
--
~Kevin
Re: Relative paths in config/syndicator.js
Posted by Cassie <do...@apache.org>.
Arne - When I change the syndicator to use
/gadgets/files/container/rpc_relay.html as the url, the request goes through
but then I get an "Invalid auth token" javascript error when calling
something like adjustHeight().
What else did you need to do to get it to work in the samplecontainer?
Or, does anybody know why an invalid auth token error would occur with this
change?
I cleaned up the samplecontainer html so that the gadget iframe isn't 100%..
which means I really want dynamic-height to work now :)
This should be reproducable from head with the one char syndicator.js
change.
- Cassie
On Fri, Mar 7, 2008 at 12:33 PM, Kevin Brown <et...@google.com> wrote:
> The default synd should be set up specifically for the sample files --
> period. If someone is using a different default path (such as a production
> site), they should provide their own syndicator config.
>
> On Fri, Mar 7, 2008 at 3:01 AM, Cassie <do...@apache.org> wrote:
>
> > Can't we just add some code to rpc.js which will append a slash if the
> > parent does not end in a slash? Or something similar to that...
> > If we can't do that then perhaps the samplecontainer should have its own
> > synd file somehow... or maybe in the sample container html init we
> should
> > just reset the parentRelayUrl to whatever it needs to be?
> >
> > (basically I just don't like changing the docs telling people it won't
> > work
> > :)
> >
> > - Cassie
> >
> >
> > On Fri, Mar 7, 2008 at 1:31 AM, Arne Roomann-Kurrik <ku...@google.com>
> > wrote:
> >
> > > I figured that this might be the case. Which is preferable then? If
> we
> > > leave it as-is, I could submit a patch for the sample container docs
> to
> > > document the need to change this value.
> > >
> > > ~Arne
> > >
> > >
> > > On Thu, Mar 6, 2008 at 4:23 PM, Zhen Wang <wa...@google.com> wrote:
> > >
> > > > The default relay URL was changed because it broke some
> non-opensocial
> > > > sample containers which pass parent parameters with a trailing
> slash.
> > > >
> > > > On Thu, Mar 6, 2008 at 4:14 PM, Kevin Brown <et...@google.com> wrote:
> > > > > Looks like an oversight. It was previously just
> files/container/...,
> > > but
> > > > > that introduced issues with different parent parameters.
> > > > >
> > > > > I think the default value should be /gadgets/files/... so that the
> > > "out
> > > > of
> > > > > the box" setup is fine, and it only has to be changed if you
> change
> > > your
> > > > > context path manually.
> > > > >
> > > > > Zhen?
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Mar 6, 2008 at 4:07 PM, Arne Roomann-Kurrik <
> > kurrik@google.com
> > > >
> > > > > wrote:
> > > > > > I'm trying to put together a demo of shindig where I download
> the
> > > > source
> > > > > > from SVN, build and run the server, and display a gadget in the
> > > > OpenSocial
> > > > > > sample container - hopefully under 10 minutes. Since I've been
> > > > playing
> > > > > > around with the sample container, I've noticed that calls to
> > > > > rpc_relay.html
> > > > > > are being directed to
> > > > > >
> > > > > >
> > > > >
> > > > http://
> > >
> >
> <my_server>:8080/gadgets/gadgets/files/container/rpc_relay.html#..................
> > > > > >
> > > > > > (note the double gadgets path) which results in a 404. I poked
> > > around
> > > > a
> > > > > bit
> > > > > > and found that the "parentRelayUrl" configuration property in
> > > > > > /config/syndicator.js is relatively pathed - prefixing a "/"
> > > provides
> > > > the
> > > > > > correct response (an "Unknown RPC service" error, but that's
> > > > expected).
> > > > > >
> > > > > > Is there a reason for the relative path in the configuration
> file?
> > > I
> > > > > > understand that this is just for testing and will be changed in
> a
> > > > > production
> > > > > > setting, but changing it in the source will make the "out of
> box"
> > > > > experience
> > > > > > a bit smoother, IMO.
> > > > > >
> > > > > > Thanks,
> > > > > > ~Arne
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ~Kevin
> > > >
> > >
> >
>
>
>
> --
> ~Kevin
>
Re: Relative paths in config/syndicator.js
Posted by Kevin Brown <et...@google.com>.
The default synd should be set up specifically for the sample files --
period. If someone is using a different default path (such as a production
site), they should provide their own syndicator config.
On Fri, Mar 7, 2008 at 3:01 AM, Cassie <do...@apache.org> wrote:
> Can't we just add some code to rpc.js which will append a slash if the
> parent does not end in a slash? Or something similar to that...
> If we can't do that then perhaps the samplecontainer should have its own
> synd file somehow... or maybe in the sample container html init we should
> just reset the parentRelayUrl to whatever it needs to be?
>
> (basically I just don't like changing the docs telling people it won't
> work
> :)
>
> - Cassie
>
>
> On Fri, Mar 7, 2008 at 1:31 AM, Arne Roomann-Kurrik <ku...@google.com>
> wrote:
>
> > I figured that this might be the case. Which is preferable then? If we
> > leave it as-is, I could submit a patch for the sample container docs to
> > document the need to change this value.
> >
> > ~Arne
> >
> >
> > On Thu, Mar 6, 2008 at 4:23 PM, Zhen Wang <wa...@google.com> wrote:
> >
> > > The default relay URL was changed because it broke some non-opensocial
> > > sample containers which pass parent parameters with a trailing slash.
> > >
> > > On Thu, Mar 6, 2008 at 4:14 PM, Kevin Brown <et...@google.com> wrote:
> > > > Looks like an oversight. It was previously just files/container/...,
> > but
> > > > that introduced issues with different parent parameters.
> > > >
> > > > I think the default value should be /gadgets/files/... so that the
> > "out
> > > of
> > > > the box" setup is fine, and it only has to be changed if you change
> > your
> > > > context path manually.
> > > >
> > > > Zhen?
> > > >
> > > >
> > > >
> > > > On Thu, Mar 6, 2008 at 4:07 PM, Arne Roomann-Kurrik <
> kurrik@google.com
> > >
> > > > wrote:
> > > > > I'm trying to put together a demo of shindig where I download the
> > > source
> > > > > from SVN, build and run the server, and display a gadget in the
> > > OpenSocial
> > > > > sample container - hopefully under 10 minutes. Since I've been
> > > playing
> > > > > around with the sample container, I've noticed that calls to
> > > > rpc_relay.html
> > > > > are being directed to
> > > > >
> > > > >
> > > >
> > > http://
> >
> <my_server>:8080/gadgets/gadgets/files/container/rpc_relay.html#..................
> > > > >
> > > > > (note the double gadgets path) which results in a 404. I poked
> > around
> > > a
> > > > bit
> > > > > and found that the "parentRelayUrl" configuration property in
> > > > > /config/syndicator.js is relatively pathed - prefixing a "/"
> > provides
> > > the
> > > > > correct response (an "Unknown RPC service" error, but that's
> > > expected).
> > > > >
> > > > > Is there a reason for the relative path in the configuration file?
> > I
> > > > > understand that this is just for testing and will be changed in a
> > > > production
> > > > > setting, but changing it in the source will make the "out of box"
> > > > experience
> > > > > a bit smoother, IMO.
> > > > >
> > > > > Thanks,
> > > > > ~Arne
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > ~Kevin
> > >
> >
>
--
~Kevin
Re: Relative paths in config/syndicator.js
Posted by Cassie <do...@apache.org>.
Can't we just add some code to rpc.js which will append a slash if the
parent does not end in a slash? Or something similar to that...
If we can't do that then perhaps the samplecontainer should have its own
synd file somehow... or maybe in the sample container html init we should
just reset the parentRelayUrl to whatever it needs to be?
(basically I just don't like changing the docs telling people it won't work
:)
- Cassie
On Fri, Mar 7, 2008 at 1:31 AM, Arne Roomann-Kurrik <ku...@google.com>
wrote:
> I figured that this might be the case. Which is preferable then? If we
> leave it as-is, I could submit a patch for the sample container docs to
> document the need to change this value.
>
> ~Arne
>
>
> On Thu, Mar 6, 2008 at 4:23 PM, Zhen Wang <wa...@google.com> wrote:
>
> > The default relay URL was changed because it broke some non-opensocial
> > sample containers which pass parent parameters with a trailing slash.
> >
> > On Thu, Mar 6, 2008 at 4:14 PM, Kevin Brown <et...@google.com> wrote:
> > > Looks like an oversight. It was previously just files/container/...,
> but
> > > that introduced issues with different parent parameters.
> > >
> > > I think the default value should be /gadgets/files/... so that the
> "out
> > of
> > > the box" setup is fine, and it only has to be changed if you change
> your
> > > context path manually.
> > >
> > > Zhen?
> > >
> > >
> > >
> > > On Thu, Mar 6, 2008 at 4:07 PM, Arne Roomann-Kurrik <kurrik@google.com
> >
> > > wrote:
> > > > I'm trying to put together a demo of shindig where I download the
> > source
> > > > from SVN, build and run the server, and display a gadget in the
> > OpenSocial
> > > > sample container - hopefully under 10 minutes. Since I've been
> > playing
> > > > around with the sample container, I've noticed that calls to
> > > rpc_relay.html
> > > > are being directed to
> > > >
> > > >
> > >
> > http://
> <my_server>:8080/gadgets/gadgets/files/container/rpc_relay.html#..................
> > > >
> > > > (note the double gadgets path) which results in a 404. I poked
> around
> > a
> > > bit
> > > > and found that the "parentRelayUrl" configuration property in
> > > > /config/syndicator.js is relatively pathed - prefixing a "/"
> provides
> > the
> > > > correct response (an "Unknown RPC service" error, but that's
> > expected).
> > > >
> > > > Is there a reason for the relative path in the configuration file?
> I
> > > > understand that this is just for testing and will be changed in a
> > > production
> > > > setting, but changing it in the source will make the "out of box"
> > > experience
> > > > a bit smoother, IMO.
> > > >
> > > > Thanks,
> > > > ~Arne
> > > >
> > >
> > >
> > >
> > > --
> > > ~Kevin
> >
>
Re: Relative paths in config/syndicator.js
Posted by Arne Roomann-Kurrik <ku...@google.com>.
I figured that this might be the case. Which is preferable then? If we
leave it as-is, I could submit a patch for the sample container docs to
document the need to change this value.
~Arne
On Thu, Mar 6, 2008 at 4:23 PM, Zhen Wang <wa...@google.com> wrote:
> The default relay URL was changed because it broke some non-opensocial
> sample containers which pass parent parameters with a trailing slash.
>
> On Thu, Mar 6, 2008 at 4:14 PM, Kevin Brown <et...@google.com> wrote:
> > Looks like an oversight. It was previously just files/container/..., but
> > that introduced issues with different parent parameters.
> >
> > I think the default value should be /gadgets/files/... so that the "out
> of
> > the box" setup is fine, and it only has to be changed if you change your
> > context path manually.
> >
> > Zhen?
> >
> >
> >
> > On Thu, Mar 6, 2008 at 4:07 PM, Arne Roomann-Kurrik <ku...@google.com>
> > wrote:
> > > I'm trying to put together a demo of shindig where I download the
> source
> > > from SVN, build and run the server, and display a gadget in the
> OpenSocial
> > > sample container - hopefully under 10 minutes. Since I've been
> playing
> > > around with the sample container, I've noticed that calls to
> > rpc_relay.html
> > > are being directed to
> > >
> > >
> >
> http://<my_server>:8080/gadgets/gadgets/files/container/rpc_relay.html#..................
> > >
> > > (note the double gadgets path) which results in a 404. I poked around
> a
> > bit
> > > and found that the "parentRelayUrl" configuration property in
> > > /config/syndicator.js is relatively pathed - prefixing a "/" provides
> the
> > > correct response (an "Unknown RPC service" error, but that's
> expected).
> > >
> > > Is there a reason for the relative path in the configuration file? I
> > > understand that this is just for testing and will be changed in a
> > production
> > > setting, but changing it in the source will make the "out of box"
> > experience
> > > a bit smoother, IMO.
> > >
> > > Thanks,
> > > ~Arne
> > >
> >
> >
> >
> > --
> > ~Kevin
>
Re: Relative paths in config/syndicator.js
Posted by Zhen Wang <wa...@google.com>.
The default relay URL was changed because it broke some non-opensocial
sample containers which pass parent parameters with a trailing slash.
On Thu, Mar 6, 2008 at 4:14 PM, Kevin Brown <et...@google.com> wrote:
> Looks like an oversight. It was previously just files/container/..., but
> that introduced issues with different parent parameters.
>
> I think the default value should be /gadgets/files/... so that the "out of
> the box" setup is fine, and it only has to be changed if you change your
> context path manually.
>
> Zhen?
>
>
>
> On Thu, Mar 6, 2008 at 4:07 PM, Arne Roomann-Kurrik <ku...@google.com>
> wrote:
> > I'm trying to put together a demo of shindig where I download the source
> > from SVN, build and run the server, and display a gadget in the OpenSocial
> > sample container - hopefully under 10 minutes. Since I've been playing
> > around with the sample container, I've noticed that calls to
> rpc_relay.html
> > are being directed to
> >
> >
> http://<my_server>:8080/gadgets/gadgets/files/container/rpc_relay.html#..................
> >
> > (note the double gadgets path) which results in a 404. I poked around a
> bit
> > and found that the "parentRelayUrl" configuration property in
> > /config/syndicator.js is relatively pathed - prefixing a "/" provides the
> > correct response (an "Unknown RPC service" error, but that's expected).
> >
> > Is there a reason for the relative path in the configuration file? I
> > understand that this is just for testing and will be changed in a
> production
> > setting, but changing it in the source will make the "out of box"
> experience
> > a bit smoother, IMO.
> >
> > Thanks,
> > ~Arne
> >
>
>
>
> --
> ~Kevin
Re: Relative paths in config/syndicator.js
Posted by Kevin Brown <et...@google.com>.
Looks like an oversight. It was previously just files/container/..., but
that introduced issues with different parent parameters.
I think the default value should be /gadgets/files/... so that the "out of
the box" setup is fine, and it only has to be changed if you change your
context path manually.
Zhen?
On Thu, Mar 6, 2008 at 4:07 PM, Arne Roomann-Kurrik <ku...@google.com>
wrote:
> I'm trying to put together a demo of shindig where I download the source
> from SVN, build and run the server, and display a gadget in the OpenSocial
> sample container - hopefully under 10 minutes. Since I've been playing
> around with the sample container, I've noticed that calls to
> rpc_relay.html
> are being directed to
>
>
> http://<my_server>:8080/gadgets/gadgets/files/container/rpc_relay.html#..................
>
> (note the double gadgets path) which results in a 404. I poked around a
> bit
> and found that the "parentRelayUrl" configuration property in
> /config/syndicator.js is relatively pathed - prefixing a "/" provides the
> correct response (an "Unknown RPC service" error, but that's expected).
>
> Is there a reason for the relative path in the configuration file? I
> understand that this is just for testing and will be changed in a
> production
> setting, but changing it in the source will make the "out of box"
> experience
> a bit smoother, IMO.
>
> Thanks,
> ~Arne
>
--
~Kevin