__MODULE_ID__: how static is it?

Hello Jack and Gurkensaft,

Here is some general information about storing user
preferences:

- Do not rely on the __MODULE_ID__ remaining static.
- You do not want to set cookies inside IFRAMEs. The default
privacy
policies of Microsoft Internet Explorer and Apple Safari do
not permit
sending cookies to third-party sites. You can read more on
this subject
here:
http://www.google.com/apis/homepage/guide.html#Cookies
- For now, we would advise you to use the Prefs.set
functionality in
order to save module settings. Unfortunately, this will
require
inlining.
http://www.google.com/apis/homepage/reference.html#JS_R
ef

I hope this helps and we thank you again for your interest
in the
Google Gadget API.

Ralph


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---

Tag Ralph!

Nicht "gurken", "gurke".  

Only German speakers make that mistake.

That's odd that you mention it shouldn't work in IE.  It
does!  Maybe
this is because the cookies are set and retrieved inside the
gadget
javascript and are not sent to any 3rd party website?  The
module is
loaded locally on the google page, so shouldn't IE and
Safari think
that it's just the browser or google setting and retrieving
cookies?
All they see is a page of code retrieved from the ig
website, right?
How do they know where the gadgets are coming from?

Let me also clarify that I am only setting these cookies as
a backup.
Every time I use prefs.set(), I also store a cookie with the
same
information, because prefs.set() often doesn't work and
loses info.
Both instances of the data have a time stamp, and I only use
the cookie
data in the event that the prefs time stamp is older than
the cookie
time stamp, and then it tries again to upload it.  That way,
the module
loses a LOT less information.

As a suggestion, maybe in the future (WAY down the line,
when you guys
are actually bored ;) the prefs.set() and prefs.get...()
functions can
do this automatically.  It would certainly make ig much more
seamless!
Think of all those times you add a module or rearrange
everything and
when you come back, it's exactly like you didn't do
anything..  Very
confusing to people who haven't thought about what's going
on in the
background.  Looks buggy, even though it's just slow
internet.  Some
simple cookie code like my hack job fixes most of this
behavior.

To stop relying on the MODULE_ID, looks like I'm going to
have to make
a hidden userpref with a unique id that's static.  How to
make a unique
ID... Get a timestamp + __MODULE_ID__ the first time the
gadget loads?

Thanks for the info!
-Jack


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---

Jack,
A thousand apologies about the name misspelling.  Oddly
enough, I no
"sprechen de deutsch".  I actually meant to
address my reply to Seige
as well.

As for the IE limitations, I suspect you might be allowing
third party
cookies in your browser.  Check your settings.  By default, 
it doesn't
allow them.  The page is being loaded from Google and if
your gadget is
trying to access cookies from another domain, I believe IE
flags it.  I
actually wish I were wrong on this point.  In particular, in
the
"Cookies" section of the documentation, you can
find the following:

Your browser is incompatible with this site as configured.
If you are
using Microsoft Internet Explorer, you can change your
security
settings by choosing Tools > Internet Options. Open the
Privacy tab,
click Advanced, and then check Override automatic cookie
handling.
Under Third-party Cookies, click Accept. Alternatively, you
can try
another web browser, such as Firefox.

I will try to get a reproducible test case that demonstrates
the
prefs.set() problems you are experiencing.  If I can do so,
I will
forward it the appropriate engineers.

Your workaround for the MODULE_ID sounds like a good one.

We appreciate the suggestions and feedback.  We are
genuinely
interested in making the gadget API the best that it can be.

Thanks again,
Ralph


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---

Hallo Ralph,

You can't speak German?  How on earth do you yell at people
when you're
angry?

Speaking of, I've tried to make IE yell at me about my
javascript
cookies, but I can't unless I tell it to prompt for 1st
party cookies.
You can try it with my gadget if you like:

http://jack.sanke
y.googlepages.com/

Every time you "x" off an item, it should try to
write a cookie.  If I
understand correctly, ig, upon loading grabs the source-code
for the
gadget and shoves it in with the rest of the html.  The only
cookie
functionality I use is javascript setting and getting from
your machine
locally.  I can't see how IE would recognize that my
javascript code
isn't from google.  Are you perhaps referring to a
different (more
common / more useful) use of cookies than what I'm doing? 
I'm probably
not using them in the way most people do, mainly because I
don't know a
thing about them 

Thanks for all your help.  I really appreciate this forum!

Jack

PS- the way to make google/ig forget things is to

(a) find a slow internet connection
(b) move lots of modules around as fast as possible and then
close the
window quickly or refresh the page

Sometimes it forgets when I remove a module, too (I'm
constantly
adding/removing developer.xml).  You have to be faster than
the ig's
upload attempts.  This was especially a big problem for my
script
because on many days it takes about a second to upload this
long string
I'm using, and if you're "x"ing off a bunch of
items very quickly,
you're making a lot of prefs.set() calls with large prefs
strings.
There was a sort of internet storm one day, and I couldn't
get it to
remember anything without waiting 3 seconds in between
clicks.  That's
all fixed now with my cookie code. Unless you're accessing
ig from two
computers simultaneously 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---

Thanks for including me into the conversation. Haha! Yeah, I
would say
that using cookie isn't the best way to store data (even
for temp),
It's also one of the reason why I searched high and low for
a module
manager that would save modules, but the existing Module
Manager store
data in cookies so i had to modify it to suit my needs:
http://design.blogdrive.com/scripts/google/module-m
anager.xml
I changed the internal memory thingy, to direct it's data
to UserPref
instead of using cookie.

It helps (me) for slow connection where it takes a long time
to load so
many modules at once. I save all the desired modules that I
don't need
at start up to speed up loading. It helps. And when I do
need them,
it's just a click away.

It feels like the windows Task Manager :p

Jack, I have another module that you might be interested as
a module
developer.
http://design.blogdrive.com/scripts/google/j
avascript-calculator.xml
It's originally supposed to be a Javascript Calculator, but
it kinda
develops into an inlined Javascript-Console. It helps with
testing some
simple javascript functions, saves time loading the homepage
just to
test if a function work or not.

Speaking of slow connection and .set() not saving
information
properly... this particular module have a string/data
"shorthener". It
appears that the more memory that's needed to be saved, the
more likely
the connection will fail. So I made it such that when the
"memory"
reach a certain size, the older data will be cut off. You
may attempt
this method if your data isn't particularly important. (it
is probably
important otherwise you won't be bothered to make a backup
cookie...
oops)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---

Hi Jack,
Thanks for the test scenarios.  I woke up this morning and
realized
that I didn't parse your post sufficiently.  You are
absolutely correct
in that you can use cookies within gadgets.  The problem
arises when
you try to send those cookies on to another domain.  For
example,
sending a login cookie to a third party site.  This was
clearly not in
the scope of your post.  My apologies again.
Regards,
Ralph


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---

Hi Jack,
Thanks for the test scenarios.  I woke up this morning and
realized
that I didn't parse your post sufficiently.  You are
absolutely correct
in that you can use cookies within gadgets.  The problem
arises when
you try to send those cookies on to another domain.  For
example,
sending a login cookie to a third party site.  This was
clearly not in
the scope of your post.  My apologies again.
Regards,
Ralph


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---

Hey Ralph!

I'm just glad there's an open forum for helpful
discussion.  I found
this dialog very helpful.

Thanks!
-Jack

Google Employee wrote:
> Hi Jack,
> Thanks for the test scenarios.  I woke up this morning
and realized
> that I didn't parse your post sufficiently.  You are
absolutely correct
> in that you can use cookies within gadgets.  The
problem arises when
> you try to send those cookies on to another domain. 
For example,
> sending a login cookie to a third party site.  This was
clearly not in
> the scope of your post.  My apologies again.
> Regards,
> Ralph


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---

> Thanks for including me into the conversation. Haha!
Yeah, I would say
> that using cookie isn't the best way to store data
(even for temp),
> It's also one of the reason why I searched high and
low for a module
> manager that would save modules, but the existing
Module Manager store
> data in cookies so i had to modify it to suit my needs:
> http://design.blogdrive.com/scripts/google/module-m
anager.xml
> I changed the internal memory thingy, to direct it's
data to UserPref
> instead of using cookie.

This is good, but it sort of transfers the problem I had to
a new
module's upload.  The problem with userprefs is that they
have a 1994
or so character limit.

> Jack, I have another module that you might be
interested as a module
> developer.
> http://design.blogdrive.com/scripts/google/j
avascript-calculator.xml
> It's originally supposed to be a Javascript
Calculator, but it kinda
> develops into an inlined Javascript-Console. It helps
with testing some
> simple javascript functions, saves time loading the
homepage just to
> test if a function work or not.

I use firebug for command line testing.  It's a plugin for
firefox .
Thanks for the heads up!

> Speaking of slow connection and .set() not saving
information
> properly... this particular module have a string/data
"shorthener". It
> appears that the more memory that's needed to be
saved, the more likely
> the connection will fail. So I made it such that when
the "memory"
> reach a certain size, the older data will be cut off.
You may attempt
> this method if your data isn't particularly important.
(it is probably
> important otherwise you won't be bothered to make a
backup cookie...
> oops)

Hehehe yeah, my data is important, from start to finish. 
I've just
compressed it, so I don't hit that size limit (mentioned
above).
prefs.set() fails if it's too large a string and doesn't
tell you, and
there's no way to check if it worked so far as I've found.
 It always
seems to work on the local variable, though, even if the
upload fails,
so you can't check with a prefs.get() until you reload the
page.

I'll have to look at the "shortening" script. 
This may prove very
useful.  I know there's more entropy to remove, because
I'm only using
numbers in my variable, wasting the information I could be
storing by
using all the string characters.  But it would be more fun
to come up
with a compression algorythm on my own ;)

Thanks!
Jack


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---

gurkesaft wrote:
...
> Hehehe yeah, my data is important, from start to
finish.  I've just
> compressed it, so I don't hit that size limit
(mentioned above).
> prefs.set() fails if it's too large a string and
doesn't tell you, and
> there's no way to check if it worked so far as I've
found.  It always
> seems to work on the local variable, though, even if
the upload fails,
> so you can't check with a prefs.get() until you reload
the page.
>

I have had this problem of prefs.set() failing silently as
well. A
friend of mine mentioned some size limitations so I have
been spanning
my data across multiple variables with a size limit on each
one of 1500
characters.  It is sort of reliable, but also sort of not.
Since set()
is an async call, would it have anything to do with
refreshing the
browser too soon after a set() call before it should have
saved?  Any
other ideas an being sure that it worked? As you mentioned,
get() gives
false positives before a refresh.

It is nice to know I'm not crazy.  Before reading this post
I thought I
was losing my mind.  Thanks.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Homepage API" group.
To post to this group, send email to Google-Homepage-APIgooglegroups.com
To unsubscribe from this group, send email to
Google-Homepage-API-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups.google.com/group/Google-Homepage-API
-~----------~----~----~----~------~----~------~--~---