Received: by 10.220.123.156 with SMTP id p28mr1482594vcr.59.1273112795148;
Wed, 05 May 2010 19:26:35 -0700 (PDT)
X-BeenThere: envjs@googlegroups.com
Received: by 10.220.47.17 with SMTP id l17ls5383775vcf.5.p; Wed, 05 May 2010
19:26:34 -0700 (PDT)
Received: by 10.220.169.134 with SMTP id z6mr64759vcy.28.1273112794521;
Wed, 05 May 2010 19:26:34 -0700 (PDT)
Received: by 10.220.169.134 with SMTP id z6mr64758vcy.28.1273112794470;
Wed, 05 May 2010 19:26:34 -0700 (PDT)
Return-Path: <thatcher.christop...@gmail.com>
Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195])
by gmr-mx.google.com with ESMTP id b14si368514vcx.5.2010.05.05.19.26.33;
Wed, 05 May 2010 19:26:33 -0700 (PDT)
Received-SPF: pass (google.com: domain of thatcher.christop...@gmail.com designates 209.85.221.195 as permitted sender) client-ip=209.85.221.195;
Received: by qyk33 with SMTP id 33so7356018qyk.24
for <envjs@googlegroups.com>; Wed, 05 May 2010 19:26:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.91.16 with SMTP id k16mr4947481qcm.40.1273112793054; Wed,
05 May 2010 19:26:33 -0700 (PDT)
Received: by 10.229.56.96 with HTTP; Wed, 5 May 2010 19:26:33 -0700 (PDT)
In-Reply-To: <98aba792-8bcf-4f58-b8cd-127412bbee76@k29g2000yqh.googlegroups.com>
References: <4BDF0960.9050007@mcn.org>
<m2qb99491f31005031306n70d62bc3tecdc5dbc2445bc9e@mail.gmail.com>
<4BDF45B2.9040908@mcn.org>
<q2mb99491f31005031756hcdd05973h4fdaf45eceb88f16@mail.gmail.com>
<4BDFAAEA.1070503@mcn.org>
<23b7de86-bd46-4aa9-a7d0-c43c0cee2db2@c7g2000vbc.googlegroups.com>
<4BE049D5.8040507@mcn.org>
<h2mb99491f31005041847j982a021dm4b7dbff549d473c5@mail.gmail.com>
<98aba792-8bcf-4f58-b8cd-127412bbee76@k29g2000yqh.googlegroups.com>
Date: Wed, 5 May 2010 22:26:33 -0400
Message-ID: <q2yb99491f31005051926y93a78086u437c9f773acbb607@mail.gmail.com>
Subject: Re: [env-js] Re: Opinions on new tests for window.location= ?
From: chris thatcher <thatcher.christop...@gmail.com>
To: envjs@googlegroups.com
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com:
domain of thatcher.christop...@gmail.com designates 209.85.221.195 as
permitted sender) smtp.mail=thatcher.christop...@gmail.com; dkim=pass (test
mode) header...@gmail.com
X-Original-Sender: thatcher.christop...@gmail.com
Reply-To: envjs@googlegroups.com
Precedence: list
Mailing-list: list envjs@googlegroups.com; contact envjs+owners@googlegroups.com
List-ID: <envjs.googlegroups.com>
List-Post: <http://groups.google.com/group/envjs/post?hl=en_US>,
<mailto:envjs@googlegroups.com>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:envjs+help@googlegroups.com>
List-Archive: <http://groups.google.com/group/envjs?hl=en_US>
Sender: envjs@googlegroups.com
List-Subscribe: <http://groups.google.com/group/envjs/subscribe?hl=en_US>,
<mailto:envjs+subscribe@googlegroups.com>
List-Unsubscribe: <http://groups.google.com/group/envjs/subscribe?hl=en_US>,
<mailto:envjs+unsubscribe@googlegroups.com>
Content-Type: multipart/alternative; boundary=001636aa2c18ca001f0485e3abad
--001636aa2c18ca001f0485e3abad
Content-Type: text/plain; charset=ISO-8859-1
Can we limit to two object literals and the function? So
Envjs.dom.Element
Envjs.html.Document
Envjs.xhr.XMLHttpRequest
etc
So basically
Envjs + source folder + class name
Thatcher
On Wed, May 5, 2010 at 4:32 PM, nickg <ni...@client9.com> wrote:
>
> The logging stuff looks hot.
>
> Back to my prototypejs 1.6 problem and namespacing, and I know glen
> also wants some type of cleanup of namespacing in the Envjs object.so,
> it that spirit, maybe something like:
>
> Envjs.dom.html.HTMLFormElemnent: type
> Envjs.dom.xhr.XMLHttpReuqest: type
>
> Envjs.dom is just the name for our all objects in the DOM that make up
> a browser (mostly our source code) (so Envjs.dom.dom would be where
> the src/dom is). I guess if the logging code was only for our dom
> stuff, then it could be simplified
>
> html.HTMLFormElement: type
> xhr.XMLHttpRequest: type,
> ...
>
>
> So it's directory + "." + class name
>
> Envjs.XXX would be other stuff not related to the dom.. like platform
> stuff, utility/common code, etc.
>
>
> That's my 2 cents, typing very quickly. I have another idea in
> another post.
>
>
> --nickg
>
>
>
> > Envjs({
> > logging:{
> > category: 'Envjs.DOM' , level: 'DEBUG',
> > category: 'Envjs.DOM.Document', level: 'INFO',
> > category: 'Envjs.XMLHttpRequest', level: 'WARN',
> > category: 'Envjs.HTML.FormElemnent', level: 'WARN',
> > category: 'root', level:
> > 'ERROR'
> > }
>
>
> On May 4, 9:47 pm, chris thatcher <thatcher.christop...@gmail.com>
> wrote:
> > skimmed closely and will reread but wanted to let you know re-logging I
> have
> > a very simple category logging implementation which I'm close to pushing
> > into the main line. The new logging api will require a small amount of
> > elbow grease to apply to the existing code base but I will step up and do
> it
> > since I'm most familiar with it.
> >
> > The huge win is that we will be able to adjust logging at startup so that
> > any category or level which is turned of will resolve to a null function
> > call and we will be able to easily modify the environment to look at a
> broad
> > or narrow category of loggers at specific levels and will *never have to
> > remove logging messages via comments*.
> >
> > This will look something like:
> >
> > Envjs({
> > logging:{
> > category: 'Envjs.DOM' , level: 'DEBUG',
> > category: 'Envjs.DOM.Document', level: 'INFO',
> > category: 'Envjs.XMLHttpRequest', level: 'WARN',
> > category: 'Envjs.HTML.FormElemnent', level: 'WARN',
> > category: 'root', level:
> > 'ERROR'
> > }
> >
> > });
> >
> > The api also allows for 'appenders' so logging io can be directed to
> various
> > platform specific plugins. Like most stuff I do, it's not anything new,
> > just an implementation of the standard approach to category logging on
> the
> > majority of platforms.
> >
> > Thatcher
> >
> > On Tue, May 4, 2010 at 12:22 PM, Glen E. Ivey <g...@mcn.org> wrote:
> >
> >
> >
> >
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> >
> > > nickg wrote:
> > > > Hi gents,
> >
> > > > Hope I"m not too late to the party.
> >
> > > Never :-)
> >
> > > > Since you are likely to mucking around with this code, I'll bring up
> > > > the implied Envjs.wait() (with no arg) is problematic.
> > > > [....]
> >
> > > Right now, I'm still hoping that this won't require messing with as I
> > > re-introduced the details of handling separate scopes. But I'll keep
> > > this in mind just in case, thanks.
> >
> > > > Glen -- hard to know what you are proposing with the "loading
> > > > proceedure" until we have something to look at.
> >
> > > > That said, I'm flexible here. Curious to see what you come up with.
> >
> > > No real proposal yet, just wanted to make sure that this degree of
> > > freedom was open, since maintaining compatibility with the existing
> load
> > > process was a primary reason that we ended up with the lame compromise
> > > last time around.
> >
> > > Right now, the first thing I plan to try is to introduce some
> > > "main()-like" behaviors into env.js itself. So, where people currently
> > > start their environment like:
> >
> > > java [options] js.jar their-code.js
> >
> > > I'm thinking we'd change to:
> >
> > > java [options] js.jar env.rhino.js their-app.whatever
> >
> > > Where the code I'd add to env.js would look at the incoming arguments,
> > > try to figure out whether the argument after "env*js" was the name/path
> > > of a JavaScript file, and HTML(-like) file, or something else, and do
> > > the right thing. If no argument is given, we'd setup for an empty
> > > window ("about:blank") and just run to the end (which I think would
> only
> > > be useful for those people actually loading env.js into an interactive
> > > Rhino shell, but who knows....).
> >
> > > Given this load mechanism, all of the JavaScript currently recommended
> > > in the README as part of loading env.js would be eliminated, including
> > > the initial call of Envjs(). If the user's code wanted to configure
> the
> > > JS runtime environment, they'd have to manipulate things through
> > > Envjs.aHook directly somewhere in "their-app.whatever" or something it
> > > loads.
> >
> > > The problem we had before that limited the use of window.location= (and
> > > equivalents) in the very first window context is that the user's
> > > JavaScript code could grab a pointer to the "real" global object before
> > > we'd put it behind a proxy, because the user's code got to execute
> > > before any env.js code. I think that there are plenty of ways to
> > > prevent that from happening going forward, but I'm hoping that
> something
> > > like this will work out and be acceptable to everyone because it seems
> > > like the cleanest to explain and the least error-prone.
> >
> > > And as long as I'm asking for early feedback, I'd be interested to hear
> > > from people who've been working on non-Rhino ports of env.js. Is
> > > something equivalent to this easy enough to do with other JavaScript
> > > interpreters? Are command-line arguments universally available to
> > > JavaScript code? If a different initialization procedure from what I'm
> > > suggesting will be needed for a non-Rhino, how important is it that all
> > > platforms start up the same way? Would it be OK to have very different
> > > startup procedures as long as the code for them could be tucked away in
> > > "platform"?
> >
> > > > Chris -- on Envjs-the-object...soon we should talk later on
> > > > "organizing" the Envjs object. Well maybe not soon, but someday ;-)
> > > > No rush on my end.
> >
> > > Well, I won't call it a rush, but sooner is definitely better for me.
> > > First, I'd like to make sure that all of the configurability we plan to
> > > continue supporting is accessible after-the-fact (via Envjs.something)
> > > since I'd like to eliminate the Envjs() function call. Second, I
> > > personally really miss the ability to adjust env.js' log level like we
> > > used to ("Envjs.logLevel = Envjs.ERROR", etc.) and want to know what
> API
> > > we plan to standardize on for this.
> >
> > > Thanks again Nick,
> > > glen
> >
> > > - --
> > > gleneivey on Skype, Y!IM, AIM, Twitter, Facebook, GitHub
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.9 (GNU/Linux)
> > > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org
> >
> > > iEYEARECAAYFAkvgSdUACgkQkocwxK1irU3TUACfUyNqfUBN0uIJNikqjrtyB7Nc
> > > i9EAoKwA1F+wshOG0IToqX5lCwyFUzRX
> > > =UhX7
> > > -----END PGP SIGNATURE-----
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Env.js" group.
> > > To post to this group, send email to envjs@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > envjs+unsubscribe@googlegroups.com<envjs%2Bunsubscribe@googlegroups.com><
> envjs%2Bunsubscribe@googlegroups.com<envjs%252Bunsubscribe@googlegroups.com>
> >.
> > > For more options, visit this group at
> > >http://groups.google.com/group/envjs?hl=en.
> >
> > --
> > Christopher Thatcher
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Env.js" group.
> > To post to this group, send email to envjs@googlegroups.com.
> > To unsubscribe from this group, send email to
> envjs+unsubscribe@googlegroups.com <envjs%2Bunsubscribe@googlegroups.com>.
> > For more options, visit this group athttp://
> groups.google.com/group/envjs?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Env.js" group.
> To post to this group, send email to envjs@googlegroups.com.
> To unsubscribe from this group, send email to
> envjs+unsubscribe@googlegroups.com <envjs%2Bunsubscribe@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/envjs?hl=en.
>
>
--
Christopher Thatcher
--
You received this message because you are subscribed to the Google Groups "Env.js" group.
To post to this group, send email to envjs@googlegroups.com.
To unsubscribe from this group, send email to envjs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/envjs?hl=en.
--001636aa2c18ca001f0485e3abad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Can we limit to two object literals and the function? So<br><br>Envjs.dom.E=
lement<br>Envjs.html.Document<br>Envjs.xhr.XMLHttpRequest<br>etc<br><br>So =
basically<br>Envjs + source folder + class name<br><br>Thatcher<br><br><div=
class=3D"gmail_quote">
On Wed, May 5, 2010 at 4:32 PM, nickg <span dir=3D"ltr"><<a href=3D"mail=
to:ni...@client9.com">ni...@client9.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
The logging stuff looks hot.<br>
<br>
Back to my prototypejs 1.6 problem and namespacing, and I know glen<br>
also wants some type of cleanup of namespacing in the Envjs object.so,<br>
it that spirit, maybe something like:<br>
<br>
Envjs.dom.html.HTMLFormElemnent: type<br>
Envjs.dom.xhr.XMLHttpReuqest: =A0type<br>
<br>
Envjs.dom is just the name for our all objects in the DOM that make up<br>
a browser (mostly our source code) (so Envjs.dom.dom would be where<br>
the src/dom is). =A0I guess if the logging code was only for our dom<br>
stuff, then it could be simplified<br>
<br>
html.HTMLFormElement: type<br>
xhr.XMLHttpRequest: type,<br>
...<br>
<br>
<br>
So it's directory + "." + class name<br>
<br>
Envjs.XXX would be other stuff not related to the dom.. like platform<br>
stuff, utility/common code, etc.<br>
<br>
<br>
That's my 2 cents, typing very quickly. =A0I have another idea in<br>
another post.<br>
<br>
<br>
--nickg<br>
<div class=3D"im"><br>
<br>
<br>
> Envjs({<br>
> =A0 =A0 logging:{<br>
> =A0 =A0 =A0 =A0 category: 'Envjs.DOM' , =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 level: 'DEBUG',<br>
> =A0 =A0 =A0 =A0 category: 'Envjs.DOM.Document', =A0 =A0 =A0 =
=A0 =A0 level: 'INFO',<br>
> =A0 =A0 =A0 =A0 category: 'Envjs.XMLHttpRequest', =A0 =A0 =A0 =
=A0 level: 'WARN',<br>
> =A0 =A0 =A0 =A0 category: 'Envjs.HTML.FormElemnent', =A0level:=
'WARN',<br>
> =A0 =A0 =A0 =A0 category: 'root', =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0level:<br>
> 'ERROR'<br>
> =A0 =A0 }<br>
<br>
<br>
</div>On May 4, 9:47=A0pm, chris thatcher <<a href=3D"mailto:thatcher.ch=
ristop...@gmail.com">thatcher.christop...@gmail.com</a>><br>
wrote:<br>
<div class=3D"im">> skimmed closely and will reread but wanted to let yo=
u know re-logging I have<br>
> a very simple category logging implementation which I'm close to p=
ushing<br>
> into the main line. =A0The new logging api will require a small amount=
of<br>
> elbow grease to apply to the existing code base but I will step up and=
do it<br>
> since I'm most familiar with it.<br>
><br>
> The huge win is that we will be able to adjust logging at startup so t=
hat<br>
> any category or level which is turned of will resolve to a null functi=
on<br>
> call and we will be able to easily modify the environment to look at a=
broad<br>
> or narrow category of loggers at specific levels and will *never have =
to<br>
> remove logging messages via comments*.<br>
><br>
> This will look something like:<br>
><br>
> Envjs({<br>
> =A0 =A0 logging:{<br>
> =A0 =A0 =A0 =A0 category: 'Envjs.DOM' , =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 level: 'DEBUG',<br>
> =A0 =A0 =A0 =A0 category: 'Envjs.DOM.Document', =A0 =A0 =A0 =
=A0 =A0 level: 'INFO',<br>
> =A0 =A0 =A0 =A0 category: 'Envjs.XMLHttpRequest', =A0 =A0 =A0 =
=A0 level: 'WARN',<br>
> =A0 =A0 =A0 =A0 category: 'Envjs.HTML.FormElemnent', =A0level:=
'WARN',<br>
> =A0 =A0 =A0 =A0 category: 'root', =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0level:<br>
> 'ERROR'<br>
> =A0 =A0 }<br>
><br>
> });<br>
><br>
> The api also allows for 'appenders' so logging io can be direc=
ted to various<br>
> platform specific plugins. =A0Like most stuff I do, it's not anyth=
ing new,<br>
> just an implementation of the standard approach to category logging on=
the<br>
> majority of platforms.<br>
><br>
> Thatcher<br>
><br>
</div><div><div></div><div class=3D"h5">> On Tue, May 4, 2010 at 12:22 P=
M, Glen E. Ivey <<a href=3D"mailto:g...@mcn.org">g...@mcn.org</a>> wr=
ote:<br>
><br>
><br>
><br>
><br>
><br>
> > -----BEGIN PGP SIGNED MESSAGE-----<br>
> > Hash: SHA1<br>
><br>
> > nickg wrote:<br>
> > > Hi gents,<br>
><br>
> > > Hope I"m not too late to the party.<br>
><br>
> > Never :-)<br>
><br>
> > > Since you are likely to mucking around with this code, I'=
;ll bring up<br>
> > > the implied Envjs.wait() (with no arg) is problematic.<br>
> > > [....]<br>
><br>
> > Right now, I'm still hoping that this won't require messi=
ng with as I<br>
> > re-introduced the details of handling separate scopes. =A0But I&#=
39;ll keep<br>
> > this in mind just in case, thanks.<br>
><br>
> > > Glen -- hard to know what you are proposing with the "l=
oading<br>
> > > proceedure" until we have something to look at.<br>
><br>
> > > That said, I'm flexible here. =A0Curious to see what you=
come up with.<br>
><br>
> > No real proposal yet, just wanted to make sure that this degree o=
f<br>
> > freedom was open, since maintaining compatibility with the existi=
ng load<br>
> > =A0process was a primary reason that we ended up with the lame co=
mpromise<br>
> > last time around.<br>
><br>
> > Right now, the first thing I plan to try is to introduce some<br>
> > "main()-like" behaviors into env.js itself. =A0So, wher=
e people currently<br>
> > start their environment like:<br>
><br>
> > =A0java [options] js.jar their-code.js<br>
><br>
> > I'm thinking we'd change to:<br>
><br>
> > =A0java [options] js.jar env.rhino.js their-app.whatever<br>
><br>
> > Where the code I'd add to env.js would look at the incoming a=
rguments,<br>
> > try to figure out whether the argument after "env*js" w=
as the name/path<br>
> > of a JavaScript file, and HTML(-like) file, or something else, an=
d do<br>
> > the right thing. =A0If no argument is given, we'd setup for a=
n empty<br>
> > window ("about:blank") and just run to the end (which I=
think would only<br>
> > be useful for those people actually loading env.js into an intera=
ctive<br>
> > Rhino shell, but who knows....).<br>
><br>
> > Given this load mechanism, all of the JavaScript currently recomm=
ended<br>
> > in the README as part of loading env.js would be eliminated, incl=
uding<br>
> > the initial call of Envjs(). =A0If the user's code wanted to =
configure the<br>
> > JS runtime environment, they'd have to manipulate things thro=
ugh<br>
> > Envjs.aHook directly somewhere in "their-app.whatever" =
or something it<br>
> > loads.<br>
><br>
> > The problem we had before that limited the use of window.location=
=3D (and<br>
> > equivalents) in the very first window context is that the user=
9;s<br>
> > JavaScript code could grab a pointer to the "real" glob=
al object before<br>
> > we'd put it behind a proxy, because the user's code got t=
o execute<br>
> > before any env.js code. =A0I think that there are plenty of ways =
to<br>
> > prevent that from happening going forward, but I'm hoping tha=
t something<br>
> > like this will work out and be acceptable to everyone because it =
seems<br>
> > like the cleanest to explain and the least error-prone.<br>
><br>
> > And as long as I'm asking for early feedback, I'd be inte=
rested to hear<br>
> > from people who've been working on non-Rhino ports of env.js.=
=A0Is<br>
> > something equivalent to this easy enough to do with other JavaScr=
ipt<br>
> > interpreters? =A0Are command-line arguments universally available=
to<br>
> > JavaScript code? =A0If a different initialization procedure from =
what I'm<br>
> > suggesting will be needed for a non-Rhino, how important is it th=
at all<br>
> > platforms start up the same way? =A0Would it be OK to have very d=
ifferent<br>
> > startup procedures as long as the code for them could be tucked a=
way in<br>
> > "platform"?<br>
><br>
> > > Chris -- on Envjs-the-object...soon we should talk later on<=
br>
> > > "organizing" the Envjs object. =A0 Well maybe not =
soon, but someday ;-)<br>
> > > No rush on my end.<br>
><br>
> > Well, I won't call it a rush, but sooner is definitely better=
for me.<br>
> > First, I'd like to make sure that all of the configurability =
we plan to<br>
> > continue supporting is accessible after-the-fact (via Envjs.somet=
hing)<br>
> > since I'd like to eliminate the Envjs() function call. =A0Sec=
ond, I<br>
> > personally really miss the ability to adjust env.js' log leve=
l like we<br>
> > used to ("Envjs.logLevel =3D Envjs.ERROR", etc.) and wa=
nt to know what API<br>
> > we plan to standardize on for this.<br>
><br>
> > Thanks again Nick,<br>
> > =A0 =A0 glen<br>
><br>
> > - --<br>
> > gleneivey on Skype, Y!IM, AIM, Twitter, Facebook, GitHub<br>
> > -----BEGIN PGP SIGNATURE-----<br>
> > Version: GnuPG v1.4.9 (GNU/Linux)<br>
> > Comment: Using GnuPG with Mozilla -<a href=3D"http://enigmail.moz=
dev.org" target=3D"_blank">http://enigmail.mozdev.org</a><br>
><br>
> > iEYEARECAAYFAkvgSdUACgkQkocwxK1irU3TUACfUyNqfUBN0uIJNikqjrtyB7Nc<=
br>
> > i9EAoKwA1F+wshOG0IToqX5lCwyFUzRX<br>
> > =3DUhX7<br>
> > -----END PGP SIGNATURE-----<br>
><br>
> > --<br>
> > You received this message because you are subscribed to the Googl=
e Groups<br>
> > "Env.js" group.<br>
> > To post to this group, send email to <a href=3D"mailto:envjs@goog=
legroups.com">envjs@googlegroups.com</a>.<br>
> > To unsubscribe from this group, send email to<br>
</div></div>> > <a href=3D"mailto:envjs%2Bunsubscr...@googlegroups.co=
m">envjs+unsubscribe@googlegroups.com</a> <<a href=3D"mailto:envjs%252Bu=
nsubscribe@googlegroups.com">envjs%2Bunsubscribe@googlegroups.com</a>>.<=
br>
<div class=3D"im">> > For more options, visit this group at<br>
> ><a href=3D"http://groups.google.com/group/envjs?hl=3Den" target=3D=
"_blank">http://groups.google.com/group/envjs?hl=3Den</a>.<br>
><br>
> --<br>
> Christopher Thatcher<br>
><br>
> --<br>
> You received this message because you are subscribed to the Google Gro=
ups "Env.js" group.<br>
> To post to this group, send email to <a href=3D"mailto:envjs@googlegro=
ups.com">envjs@googlegroups.com</a>.<br>
> To unsubscribe from this group, send email to <a href=3D"mailto:envjs%=
2Bunsubscribe@googlegroups.com">envjs+unsubscribe@googlegroups.com</a>.<br>
</div>> For more options, visit this group athttp://<a href=3D"http://gr=
oups.google.com/group/envjs?hl=3Den" target=3D"_blank">groups.google.com/gr=
oup/envjs?hl=3Den</a>.<br>
<font color=3D"#888888"><br>
--<br>
</font><div><div></div><div class=3D"h5">You received this message because =
you are subscribed to the Google Groups "Env.js" group.<br>
To post to this group, send email to <a href=3D"mailto:en...@googlegroups.c=
om">envjs@googlegroups.com</a>.<br>
To unsubscribe from this group, send email to <a href=3D"mailto:envjs%2Buns=
ubscribe@googlegroups.com">envjs+unsubscribe@googlegroups.com</a>.<br>
For more options, visit this group at <a href=3D"http://groups.google.com/g=
roup/envjs?hl=3Den" target=3D"_blank">http://groups.google.com/group/envjs?=
hl=3Den</a>.<br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Christopher=
Thatcher<br>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups "=
Env.js" group.<br />
To post to this group, send email to envjs@googlegroups.com.<br />
To unsubscribe from this group, send email to envjs+unsubscribe@googlegroup=
s.com.<br />
For more options, visit this group at http://groups.google.com/group/envjs?=
hl=3Den.<br />
Message from discussion Opinions on new tests for window.location= ?
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |