how is a gadget supposed to use the opensocial-samplecontainer then? the samplecontainer is simply a special version of opensocial-.. i suppose we could call is opensocial-0.0 or something if you really want to.
opensocial-reference needs to be a feature because of the way feature dependencies are set up. both opensocial-0.6 and opensocial-0.7 etc will rely on it. if you give me a way to reference the opensocial reference js code from the javascript directory that's fine but right now it has to be a feature because of what you wrote :) state can not be stored in the parent site because of how opensocial works right now (ie all of opensocial is put into that iframe, and the state files modify what is inside the iframe.) i suppose i could change it to use ifpc but that is just a silly amount of work. this use case should be supported. it isn't wrong in any way and there are certainly other features that could come up that might want to do things in this fashion. i understand it will be easier later, but it isn't easier right now. why can't i just have some cookies? this data is not secure, it does not matter if it gets wiped and is purely for convenience. i can't use setprefs in this case because the pref is not defined in the gadget xml and is added dynamically. if you give me the ability to add prefs outside of the gadget xml spec then that would be fine. if i can't get cookies in a nice way, like i said before, i will just have to copy cookies.js into the feature itself. that is just silly. it doesn't need to be part of the spec at all, but it needs to be accessible. - Cassie On Wed, Jan 23, 2008 at 12:24 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > opensocial-samplecontainer and opensocial-reference shouldn't be features > either (the feature dependency should be "opensocial-0.6" or " > opensocial-0.7", > or whatever we actually have support for), it should be a gadget, and > state > should be stored in the parent site. Right now this means you'd have to > use > inter frame communication to pass the data, but when/if we get an > SignedDataServlet in place the open social code can use that to just do an > XHR. > > You may want to save cookies, but we explicitly don't do it on purpose, > because it's a big security vulnerability. You can never rely on cookies > being available between page renders (on igoogle the domain changes every > time you move a gadget on your page and on orkut the domain changes every > month or so), and when gadgets are cajoled writing cookies will be > disabled > completely. Gadget developers are told to use setprefs for storing data > (and > with open social we'll have the infinitely more robust appdata to rely > on). > The parent site may store / read cookies to implement setprefs and > appdata, > but actual cookie interaction is intentionally not a part of the gadget > spec > for these reasons. > > ~Kevin > > On Jan 23, 2008 9:57 AM, Cassie <[EMAIL PROTECTED]> wrote: > > > I was the one who wanted cookies. > > I disagree that you will never want to save cookies from within the > > iframe. > > I need to do it from within the iframe in the sample container (for the > > state file) and so it seems like we should come up with a clean way to > do > > this. (I also don't think it is too far fetched that other libraries may > > need it in the future but we can table that for now) > > > > I can of course copy the cookies.js code into the sample container > > features > > folder but that is just a gross code duplication issue. Is there a way I > > can > > reference the cookies.js file from within the samplecontainer > feature.xmlas > > it stands right now? > > > > - Cassie > > > > > > > > On Wed, Jan 23, 2008 at 9:50 AM, John Hjelmstad (JIRA) <[EMAIL PROTECTED]> > > wrote: > > > > > > > > [ > > > > > > https://issues.apache.org/jira/browse/SHINDIG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561746#action_12561746 > > ] > > > > > > John Hjelmstad commented on SHINDIG-32: > > > --------------------------------------- > > > > > > This was a quick hack used to get the JS Container code in quickly. > I'll > > > be removing it over time. > > > > > > > cookies.js should not be under a goog. namespace. > > > > ------------------------------------------------- > > > > > > > > Key: SHINDIG-32 > > > > URL: > https://issues.apache.org/jira/browse/SHINDIG-32 > > > > Project: Shindig > > > > Issue Type: Improvement > > > > Components: Javascript > > > > Reporter: Cassie Doll > > > > Assignee: Kevin Brown > > > > Original Estimate: 1h > > > > Remaining Estimate: 1h > > > > > > > > The cookies.js file needs to be renamespaced to something else. It > > would > > > also be helpful if it was moved into a feature so that other features > > could > > > depend on it. > > > > > > -- > > > This message is automatically generated by JIRA. > > > - > > > You can reply to this email to add a comment to the issue online. > > > > > > > > >
