Patch committed. I'll be continuing to test this in various configurations.
Please don't hesitate to contact me w/ any bugs you may find.
Best,
John
On Mon, Jun 29, 2009 at 3:15 PM, John Hjelmstad wrote:
> Thanks Paul-
> Thanks for the push ;) I'm on it. I'm finishing some sanity testing on this
Thanks Paul-
Thanks for the push ;) I'm on it. I'm finishing some sanity testing on this
right now and will commit shortly.
--John
On Mon, Jun 29, 2009 at 3:01 PM, Paul Lindner wrote:
> Thanks John,
> If you don't commit it today, I will.
>
> On Thu, Jun 25, 2009 at 2:30 PM, John Hjelmstad wrot
Thanks John,
If you don't commit it today, I will.
On Thu, Jun 25, 2009 at 2:30 PM, John Hjelmstad wrote:
> Thanks for your continued comments-
> I've created a new patch removing document.postMessage(...) from the code.
> I agree that Opera8 usage is so tiny as to be deemed nonexistent.
>
> For
looks quite good to me, the rest of the issues can be pushed out to later.
Thanks again for all the work that went into this.
Paul
On Thu, Jun 25, 2009 at 2:30 PM, John Hjelmstad wrote:
> Thanks for your continued comments-
> I've created a new patch removing document.postMessage(...) from the
Thanks for your continued comments-
I've created a new patch removing document.postMessage(...) from the code. I
agree that Opera8 usage is so tiny as to be deemed nonexistent.
For the moment, I'm keeping the rest though. Much as I'd like to get rid of
unregisterX(...), I'm seeing quite a few refe
Reviewers: shindig.remailer_gmail.com,
Description:
1. RMR, new transport for Safari < 4, Chrome < 2, and should work as a
backup on several other browsers (the latter claim requires more
testing).
- Paves the way to sunsetting IFPC, in turn sunsetting the need for
containers to host "active" r
Funny, I found the serialize/deserialize an issue because people developing
might pass js objects back and forth, but I say let it in if Evan says it's
useful.
Can we get this patch committed now? Are we all in agreement?
On Fri, Jun 19, 2009 at 2:15 PM, wrote:
>
> http://codereview.appspot.co
http://codereview.appspot.com/63209/diff/1/2
File features/src/main/javascript/features/rpc/rpc.js (right):
http://codereview.appspot.com/63209/diff/1/2#newcode339
Line 339: function callSameDomain(target, rpc) {
On 2009/06/11 09:32:21, etnu00 wrote:
This really belongs in a file shared by 'slo
The rpc changes are looking good. I'm +1 on getting rid of dpm -- Opera 8
usage is largely nonexistent.\I'm +0 on keeping the getType() method in
place, as it adds value. (Maybe we need a #ifdef DEBUG for our JsLoader?)
I'm +1 on deleting callSameDomain() -- it can cause subtle problems if
people
Thanks for the feedback, comments inline. For many responses, I'm interested
in your take. I've made a few changes to code but will defer momentarily in
submitting another patch to keep the dialog running.
On Thu, Jun 11, 2009 at 2:32 AM, wrote:
>
> http://codereview.appspot.com/63209/diff/1/5
>
Does this mean gfc might be able to stop requiring the relay file? Cool if
so. Is ETA weeks/months/quarters?
On Jun 8, 2009 7:10 PM, wrote:
Reviewers: shindig.remailer_gmail.com,
Description:
1. RMR, new transport for Safari < 4, Chrome < 2, and should work as a
backup on several other browse
http://codereview.appspot.com/63209/diff/1/5
File features/src/main/javascript/features/rpc/dpm.transport.js (right):
http://codereview.appspot.com/63209/diff/1/5#newcode28
Line 28: */
I vote to delete this entirely.
http://codereview.appspot.com/63209/diff/1/2
File features/src/main/javascript
Reviewers: shindig.remailer_gmail.com,
Description:
1. RMR, new transport for Safari < 4, Chrome < 2, and should work as a
backup on several other browsers (the latter claim requires more
testing).
- Paves the way to sunsetting IFPC, in turn sunsetting the need for
containers to host "active" r
On Thu, May 7, 2009 at 2:45 PM, Brian Eaton wrote:
> On Thu, May 7, 2009 at 2:32 PM, John Hjelmstad wrote:
> >> - no-store cache control headers
> >
> > Don't appear to affect this.
>
> Wow. Weird. I would have guessed that it would trigger HTTP requests
> on every RPC. Or are you getting to
On Thu, May 7, 2009 at 2:32 PM, John Hjelmstad wrote:
>> - no-store cache control headers
>
> Don't appear to affect this.
Wow. Weird. I would have guessed that it would trigger HTTP requests
on every RPC. Or are you getting to reuse existing iframes?
> ...as would 401s on account of auth pop
On Thu, May 7, 2009 at 11:10 AM, Brian Eaton wrote:
> On Thu, May 7, 2009 at 10:57 AM, John Hjelmstad wrote:
> > None of which I'm aware. The RMR relay is (receiver's)
> > protocol://host:port/robots.txt, which doesn't even need to exist or be
> > served "correctly" (404/500 OK). It would be ni
On Thu, May 7, 2009 at 10:57 AM, John Hjelmstad wrote:
> None of which I'm aware. The RMR relay is (receiver's)
> protocol://host:port/robots.txt, which doesn't even need to exist or be
> served "correctly" (404/500 OK). It would be nice for this file to be
> heavily cached but at least it's a on
Thanks for the feedback, Brian. Comments inline.
On Wed, May 6, 2009 at 10:05 PM, Brian Eaton wrote:
> Thanks for the heads-up.
>
> I love the idea of refactoring gadgets.rpc into smaller bits.
>
> There are existing type=url gadgets that rely on verifying the domain
> of the parent page in orde
Thanks for the heads-up.
I love the idea of refactoring gadgets.rpc into smaller bits.
There are existing type=url gadgets that rely on verifying the domain
of the parent page in order to function securely. Today they can do
that by enforcing use of IFPC or WPM and checking the relay URL. That
Hello,
I've been implementing some improvements to rpc.js, and have a few more
planned, so wanted to give everyone a heads-up.
Issue (https://issues.apache.org/jira/browse/SHINDIG-1050) describes a new
transport mechanism I (with significant help from Joey Schorr) have
implemented called RMR. Nitt
20 matches
Mail list logo
