On Tue, Feb 17, 2009 at 4:02 PM, Priestley, Mark, VF-Group
wrote:
> Hi Marcos, All,
>
> I think we're all roughly on the same page about potential changes to
> the localisation model and should therefore be able to specify something
> that keeps everyone happy. I'll try and illustrate using an exa
On Tue, Feb 17, 2009 at 2:15 AM, Scott Wilson
wrote:
> Jonas,
>
> One level of indirection is a very small price to pay for much more
> implementation flexibility.
But like I pointed out earlier, and if I understand the problem
correctly, your suggested solution will only work temporarily. It wil
You are correct that there are a number of other means in information
can be coopted. So trying to limit access via the originating site would
essentially be useless.
Thanks
Mike Chack
O: +1 408.526.4639
M: +1 408.504.6594
mch...@cisco.com
-Original Message-
From: Anne van Kesteren [
All,
Mark has explained the logic quite nicely below. The normal handling is a bit
like the HTML base URI; you use relative URIs but the base is different
depending on the user's language. There needs to be a fallback mechanism like
this for all those resources that are not found in a given loc
Hi Marcos, All,
I think we're all roughly on the same page about potential changes to
the localisation model and should therefore be able to specify something
that keeps everyone happy. I'll try and illustrate using an example.
Widget resource is localised, with the following file structure:
/c
Mike Chack (mchack) wrote on 2/16/2009 9:25 AM:
> Unless I am missing something, there seems to be a security hole with
> the current proposal. If a site has been hacked then malicous code can
> send content to any site that abides by the access control policies. It
> is up to the destination sit
On Feb 17, 2009, at 12:30 , Anne van Kesteren wrote:
On Tue, 17 Feb 2009 12:26:16 +0100, Cameron McCormack
wrote:
Charles McCathieNevile:
If anyone objects to this approach (which saves some administrative
work and some time), please speak up...
Web IDL is still a WD. At some point before
On Tue, 17 Feb 2009 12:26:16 +0100, Cameron McCormack
wrote:
Charles McCathieNevile:
If anyone objects to this approach (which saves some administrative
work and some time), please speak up...
Web IDL is still a WD. At some point before Rec, I guess selectors-api
would need to block on Web
Charles McCathieNevile:
> If anyone objects to this approach (which saves some administrative
> work and some time), please speak up...
Web IDL is still a WD. At some point before Rec, I guess selectors-api
would need to block on Web IDL progressing. What point should that be?
--
Cameron McCor
On Mon, 16 Feb 2009 18:14:10 +0100, Mike Chack (mchack)
wrote:
Unless I am missing something, there seems to be a security hole with
the current proposal. If a site has been hacked then malicous code can
send content to any site that abides by the access control policies. It
is up to the desti
Unless I am missing something, there seems to be a security hole with
the current proposal. If a site has been hacked then malicous code can
send content to any site that abides by the access control policies. It
is up to the destination site to accept the request, and in the case of
a nefarious d
Unless I am missing something, there seems to be a security hole with
the current proposal. If a site has been hacked then malicous code can
send content to any site that abides by the access control policies. It
is up to the destination site to accept the request, and in the case of
a nefarious d
On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile
wrote:
this is a call for consensus to move the Selectors API [1] to Candidate
Recommendation, following the end of the last call. The disposition of
comments[2] has no formal objections, and I believe all substantive
issues are
Jonas,
One level of indirection is a very small price to pay for much more
implementation flexibility. It won't hurt developers (the methods are
equivalent) and it decouples the specifications enough to support
different deployment models.
What (I think - correct me if I'm wrong) you've b
Hello Jonas.
I think there is a bit of confusion here.
In the beginning I proposed the HTML 5 Local Storage implementation, but
was not "accepted" because there were (and there are) problems related
to some specs of HTML 5 that simply "don't fit" the Widget scenario.
At the same time, I see the a
Hi All,
I would like to inform everyone that I now represent Opera Software in
this Working Group (hence, I no longer have invited expert status). My
role as editor of the various widget specifications will continue as
normal, though l will unlikely be able to respond to emails as quickly
as usual
16 matches
Mail list logo
