There is now an Editing Explainer [1] and a User Intentions Explainer [2],
which should help scope the problems and help us drive forward on both areas. I
haven't done much to fine tune them yet, but please let me know if you have
feedback on this split from the initial Commands Explainer docume
On 2014-09-05 19:34, Валерий Котов wrote:
...
Thank you everybody for responses!
> Out of curiosity - do you have a use case where you need to be able
to send "OPTIONS *"?
Unfortunately, I can't think of any specific use case except getting
general server settings. For example (from specificati
2014-09-05 13:28 GMT+03:00 Julian Reschke :
> On 2014-09-04 20:32, Валерий Котов wrote:
>
>> Greetings everybody!
>>
>> My name is Valery. I'm currently working on adding support for "OPTION"
>> http request method for XMLHttpRequest class inside Qt framework.
>> According to RFC (http://tools.iet
I just figured handling the Java2Script (Java to JavaScript) conversion
into an ES6 module format would be substantially easier as the syntax is
much more similar to Java's own than, say, AMD.
But yes, it does add another layer of indirection via transpilation.
Sincerely,
James Greene
On
Java -> JavaScript that works totally asynchronously is the plan.
Should have that working relatively soon.
x = load("file00"+ (++i) + ".pdb")
but we can live with that.
Bob Hanson
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26736
Bug ID: 26736
Summary: Does the final progress event need to be dispatched
after readystatechange?
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS
FWIW I do not think ES6 modules are a good solution for your problem. Since
they are not in browsers, you would effectively be adding a layer of
indirection (the “transpilation” James discusses) that serves no purpose
besides to beta-test a future platform feature for us. There are much more
st
On Friday, September 5, 2014, Kostiainen, Anssi
wrote:
> On 04 Sep 2014, at 23:18, Marcos Caceres > wrote:
>
> > Absolutely, we should be addressing them at the API level.
>
> I guess you mean each API should address this in a way that fits the
> design of the particular API the best?
Correct.
On 04 Sep 2014, at 23:18, Marcos Caceres wrote:
> Absolutely, we should be addressing them at the API level.
I guess you mean each API should address this in a way that fits the design of
the particular API the best?
And something like permissions.js could then be used to abstract away the
di
On 2014-09-04 20:32, Валерий Котов wrote:
Greetings everybody!
My name is Valery. I'm currently working on adding support for "OPTION"
http request method for XMLHttpRequest class inside Qt framework.
According to RFC (http://tools.ietf.org/html/rfc2616#page-52) request
uri can contian asterisk
On Fri, Sep 5, 2014 at 11:14 AM, Mounir Lamouri wrote:
> Note that the Permissions API model isn't requiring all APIs to abide by
> its model. Having no permissions at all for an API is a decent model if
> possible. For example, having a permission concept for type='file'> doesn't make much sens
On Fri, 5 Sep 2014, at 03:23, Edward O'Connor wrote:
> We should be avoiding adding features to the platform that have to
> resort to explicit permissioning. Instead of adding features which
> require prompting for permission, we should be designing features—like
> drag & drop or —that don't requir
On 2014-09-05 10:03, Anne van Kesteren wrote:
On Thu, Sep 4, 2014 at 11:09 PM, Mark Nottingham wrote:
Huh?
OPTIONS * isn’t exactly common, but it’s very much OK by HTTP…
Sure. It's not supported by XMLHttpRequest. If you pass "*" as URL
argument, you'll get a request for "/baseURL/*". And si
On Fri, Sep 5, 2014 at 10:06 AM, Mark Nottingham wrote:
> That would be foolish, since browsers don’t have an exclusive license to emit
> HTTP requests.
No, but only browsers are capable of executing untrusted requests
within the current network of the user. But if OPTIONS * is not so
important,
On 5 Sep 2014, at 11:03 am, Anne van Kesteren wrote:
> On Thu, Sep 4, 2014 at 11:09 PM, Mark Nottingham wrote:
>> Huh?
>>
>> OPTIONS * isn’t exactly common, but it’s very much OK by HTTP…
>
> Sure. It's not supported by XMLHttpRequest. If you pass "*" as URL
> argument, you'll get a request f
On Thu, Sep 4, 2014 at 11:09 PM, Mark Nottingham wrote:
> Huh?
>
> OPTIONS * isn’t exactly common, but it’s very much OK by HTTP…
Sure. It's not supported by XMLHttpRequest. If you pass "*" as URL
argument, you'll get a request for "/baseURL/*". And since it's not
supported by XMLHttpRequest, ser
On Thu, Sep 4, 2014 at 9:58 PM, Douglas Sherk wrote:
> A use case I can see for this is setting webapp wallpapers and wanting to see
> if an image that a user uploaded is the same as one already in a gallery, but
> without having to query a server or store them as anything other than blobs.
If
This is the most up-to-date reference, btw:
http://httpwg.github.io/specs/rfc7230.html#asterisk-form
On 4 Sep 2014, at 9:32 pm, Валерий Котов wrote:
> Greetings everybody!
>
> My name is Valery. I'm currently working on adding support for "OPTION" http
> request method for XMLHttpRequest cl
Greetings everybody!
My name is Valery. I'm currently working on adding support for "OPTION"
http request method for XMLHttpRequest class inside Qt framework.
According to RFC (http://tools.ietf.org/html/rfc2616#page-52) request uri
can contian asterisk ("*"). Please see quotation from RFC below.
Hi all,
Currently, there's no way to compare the contents of two Blobs without writing
your own byte-by-byte comparison. A use case I can see for this is setting
webapp wallpapers and wanting to see if an image that a user uploaded is the
same as one already in a gallery, but without having to
21 matches
Mail list logo
