Mailing-List: contact dev-help@shindig.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shindig.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 ddumont@us.ibm.com does not designate 192.147.106.25 as permitted sender)
In-Reply-To: <CB432ABF.D41C%daviesd@oclc.org>
References: 
 <OFC780B221.35295B2F-ON8525798E.006ECCAA-8525798E.006F5783@notesdev.ibm.com>
 <CB432ABF.D41C%daviesd@oclc.org>
To: dev@shindig.apache.org
MIME-Version: 1.0
Subject: Re: getModuleId
From: "Dan Dumont" <ddumont@us.ibm.com>
Message-ID: 
 <OFF2455330.03B2319B-ON8525798E.00700A95-8525798E.0073D7CC@notesdev.ibm.com>
Date: Mon, 23 Jan 2012 16:05:19 -0500
Content-Type: multipart/alternative;
 boundary="=_alternative 0073D7AD8525798E_="

--=_alternative 0073D7AD8525798E_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

The server side moduleId stuff is all there for you to implement however=20
you want to persist gadget instances.=20

It should be fairly flexible so that you can implement it many different=20
ways.  Just inject your implementation in place of shindig's module id=20
manager
I have a spec patch out there that specifies how to use the moduleId=20
render param when navigating a gadget.


From:   daviesd <daviesd@oclc.org>
To:     <dev@shindig.apache.org>,=20
Date:   01/23/2012 03:19 PM
Subject:        Re: getModuleId


That's what I was kind of figuring.  So can you tell me what state the
moduleId stuff is at?  Is it still under development or can I start using=20
it
now?  I hope we get another beta (or final 3.0.0 release) soon that has=20
this
and oauth2 in a stable state.

doug


On 1/23/12 3:16 PM, "Dan Dumont" <ddumont@us.ibm.com> wrote:

> Hrmm...
>=20
> I don't know if you'll be able to do this anymore until you hook up the
> moduleId support.
>=20
>=20
>=20
> From:   daviesd <daviesd@oclc.org>
> To:     <dev@shindig.apache.org>,
> Date:   01/23/2012 03:08 PM
> Subject:        Re: getModuleId
>=20
>=20
>=20
> Like I said... An edge case... And probably not a real world use case.
>=20
> But my test gadget sets a bunch of userprefs and then it needs to repull
> the
> values (from persistence) and make sure they've been set properly (tests =

a
> race condition we had).
>=20
> I was using osapi.userprefs.get to retrieve the values.  Is there a=20
gadget
> way of triggering the get call that is in the container?  I don't want=20
to
> just get the map that the container has, I need to reforce a read from
> persistence.
>=20
> Hope that makes sense,
> doug
>=20
>=20
> On 1/23/12 3:00 PM, "Dan Dumont" <ddumont@us.ibm.com> wrote:
>=20
>> I don't think so.   In my opinion, the siteId is a purely container
> piece
>> of information.
>> why do you need to get it inside the gadget?
>>=20
>>=20
>>=20
>> From:   daviesd <daviesd@oclc.org>
>> To:     <dev@shindig.apache.org>,
>> Date:   01/23/2012 02:57 PM
>> Subject:        Re: getModuleId
>>=20
>>=20
>>=20
>> I agree on everything you just stated.
>>=20
>> So my only outstanding question would be is anyone aware of a way for a
>> gadget to find out it's siteId (the id that was set on the element the
>> gadget was rendered into)?
>>=20
>> Any yes, I'd like to see the rpc requests changed to use the gadget
>> security
>> token.
>>=20
>> doug
>>=20
>>=20
>> On 1/23/12 1:44 PM, "Dan Dumont" <ddumont@us.ibm.com> wrote:
>>=20
>>> Not a problem.
>>>=20
>>> mid is for the moduleId.  (maybe it wasn't always so... but for
>>> consistency sake it probably should remain so)
>>> IIRC, Prefs.getModuleId returns the value in the ifr url 'mid' param.
>>>=20
>>> Your GET=5FPREFERENCES/SET=5FPREFERENCES impl should be getting the=20
siteid,
>>> which it can look up a gadget site with.
>>> You can then determine the moduleId (which should be 0 for now).
>>>=20
>>> I agree, if the rpc requests do not pass the gadget's token along,=20
they
>>> probably should now.  Most people will be wanting to key things off of
>> the
>>> moduleId rather than the siteId.  The moduleId is baked in the token
> and
>>> not something one could spoof with firebug.
>>>=20
>>>=20
>>> From:   daviesd <daviesd@oclc.org>
>>> To:     <dev@shindig.apache.org>,
>>> Date:   01/23/2012 01:34 PM
>>> Subject:        Re: getModuleId
>>>=20
>>>=20
>>>=20
>>> In pref.js shindig was setting the Prefs moduleId to the "mid"
>> parameter.
>>> Perhaps something is different here now.  So for whatever reason that
>> use
>>> to
>>> return me whatever I had as my siteId and now it doesn't.
>>>=20
>>> At any rate, this is a TEST gadget that is probably trying to access
>>> something it shouldn't.  When the userprefs are stored they are stored
>>> using
>>> the siteId granted by our container implementation (the container
>>> registers
>>> SET=5FPREFERENCES and GET=5FPREFERENCES handlers).  I think I opened up
> this
>>> ticket because of that.
>>>=20
>>> https://issues.apache.org/jira/browse/SHINDIG-1557
>>>=20
>>> It would really be nice if the rpc requests used the gadget security
>> token
>>> (that would hopefully have the moduleId set now that you've=20
implemented
>>> that).
>>>=20
>>> So in my test gadget I don't know what the siteId is.  For some reason
> I
>>> was
>>> calling Prefs().getModuleId (I think this thread suggests that).
>>>=20
>>> http://shindig-dev.markmail.org/thread/zyi2zvpn7akhrbi3
>>>=20
>>> Is there another way for a gadget to know this?  I realize=20
implementing
>>> moduleId would probably give me this (although a gadget doesn't really
>>> know
>>> what's in it's security token, but it can certainly pass it along to
> api
>>> calls).
>>>=20
>>> Sorry if I'm muddying the waters.  I should have been more active in
>> your
>>> moduleId discussion.
>>>=20
>>> doug
>>>=20
>>>=20
>>> On 1/23/12 12:57 PM, "Dan Dumont" <ddumont@us.ibm.com> wrote:
>>>=20
>>>> Hrmm... I don't recall moduleId ever being anything other than 0.
>>>>=20
>>>> The discussions have focused around what a moduleId is (a number
> that's
>>>> baked into the security token, primarily used to identify saved
>>> instances
>>>> of a gadget) and what a siteId is ( a string value that's used in or
> as
>>> an
>>>> id attribute of a DOM element in the container ).  The recent patches
>>>> created a way to generate, save, and track moduleIds on the server,
>>> should
>>>> you choose to implement the bits, otherwise they return 0 as they
>> always
>>>> have.
>>>>=20
>>>> I'm curious how you got numbers other than 0.  Especially for the
>>> security
>>>> token, moduleId was always 0 in shindig.
>>>>=20
>>>>=20
>>>>=20
>>>> From:   daviesd <daviesd@oclc.org>
>>>> To:     shindig <dev@shindig.apache.org>,
>>>> Date:   01/23/2012 12:51 PM
>>>> Subject:        getModuleId
>>>>=20
>>>>=20
>>>>=20
>>>> I have a gadget that was using
>>>>=20
>>>> var moduleId =3D new gadgets.Prefs().getModuleId();
>>>>=20
>>>> To get the current moduleId (siteId) of the gadget so that it could
>>>> retrieve
>>>> userprefs
>>>>=20
>>>> osapi.userprefs.get( { siteId : moduleId } )
>>>>=20
>>>> This is now return 0 instead of the id I have for the element the
>> gadget
>>>> was
>>>> rendered into.
>>>>=20
>>>> I haven=B9t kept up with the whole moduleId/siteId patch that is going
>> on,
>>>> but
>>>> perhaps something has changed here and is not backwards compatible?
>>>>=20
>>>> Any ideas?  It=B9s been a while since I=B9ve played around with userpr=
efs
>>> and
>>>> today was the first I noticed it wasn=B9t working.
>>>>=20
>>>> doug
>>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>>=20
>=20
>=20
>=20


--=_alternative 0073D7AD8525798E_=--