How about using ES7 decorators, like so:
@idb_promise
function () {
//some code that uses the IDB API in Promise based way
}
and it would add .promise to the IDB APIs
On Mon, Sep 28, 2015 at 1:26 PM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:
> On 28/09/15 22:14, M
l config.
On Mon, Sep 28, 2015 at 1:12 PM, Marc Fawzi wrote:
> Yes, sorry.
>
> < underlying issue of mixing IDB+Promises remains. >>
>
> That's for implementors such as yourself to work through, I had assumed.
>
> I just went over the Readme from the perspective o
thing I can think of is a timeout that is configurable
on waitUntil, e.g. waitUntil(new Promise()).maxTime(30s)
On Mon, Sep 28, 2015 at 12:36 PM, Joshua Bell wrote:
> On Mon, Sep 28, 2015 at 11:42 AM, Marc Fawzi wrote:
>
>> Have you looked at ES7 async/await? I find that patter
Have you looked at ES7 async/await? I find that pattern makes both simple as
well as very complex (even dynamic) async coordination much easier to deal with
than Promise API. I mean from a developer perspective.
Sent from my iPhone
> On Sep 28, 2015, at 10:43 AM, Joshua Bell wrote:
>
> One
ve done work in all three areas, collaborating with Intel
> and Google people at least. Ongoing work continues as far as I know. Again,
> some of it may be better done in groups other than public-webapps. I cited
> roc's blog post about custom view scrolling, which seems to fall under
Travis,
That would be awesome.
I will go over that link and hopefully have starting points for the
discussion.
My day job actually allows me to dedicate time to experimentation (hence
the ClojureScript stuff), so if you have any private branches of IE with
latest DOM experiments, I'd be very hap
is pursuing)
On Thu, Feb 12, 2015 at 3:46 AM, Aryeh Gregor wrote:
> On Thu, Feb 12, 2015 at 4:45 AM, Marc Fawzi wrote:
> > how long can this be sustained? forever? what is the point in time where
> the
> > business of retaining backward compatibility becomes a huge nightma
this "backward compatibility" stuff is making me think that the web is
built upon the axiom that we will never start over and we must keep piling
up new features and principles on top of the old ones
this has worked so far, miraculously and not without overhead, but I can
only assume that it's at
ssions, vagueness is not the enemy of
the truth, only part of the journey... Relax.
On a more serious basis, please provide us with clarity or point us to
discussions on this topic that might help us understand how to get _to_
there!
On Tue, Feb 10, 2015 at 7:19 PM, Brendan Eich
wrote:
>
Dropping words like immutable and
> lock-free doesn't help. That, plus a lot of attitude about deprecating sync
> XHR (on all sides; I'm not in favor of useless deprecation, myself -- good
> luck to browsers who "go first" on actually *removing* sync XHR support),
>
e going strong. Work there, above
> the standards. De-jure standardization will follow, and we'll all be better
> off for that order of work.
>
> /be
>
> Marc Fawzi wrote:
>> How about a thread-safe but lock-free version of the DOM based on something
>> like Clojur
e'll all be better
> off for that order of work.
>
> /be
>
> Marc Fawzi wrote:
>> How about a thread-safe but lock-free version of the DOM based on something
>> like Clojure's atom? So we can manipulate the DOM from web workers? With
>> cursor suppor
e the picture.
I think maybe aside from the thread-safe DOM idea, everything below that
should belong to the ES7 discussion list.
On Tue, Feb 10, 2015 at 1:46 PM, Marc Fawzi wrote:
>
> How about a thread-safe but lock-free version of the DOM based on
> something like Clojure's ato
from my iPhone
> On Feb 10, 2015, at 1:09 PM, Jonas Sicking wrote:
>
>> On Tue, Feb 10, 2015 at 12:51 PM, Marc Fawzi wrote:
>> i agree that it's not a democratic process and even though some W3C/TAG
>> people will engage you every now and then the end result
eam and both
> groups should cooperate better for the benefit of all web users.
>
> m.
>
>
> On 02/10/2015 02:01 PM, Marc Fawzi wrote:
> > <<
> > Reminds me on the days when
> > Microsoft was trying to tell me what's good and what's not good.
>
<<
Reminds me on the days when
Microsoft was trying to tell me what's good and what's not good.
>>
At least Microsoft didn't put a backdoor in Windows that can divulge your
local IP (within a LAN) to the outside world. They call it WebRTC. If you
want something to complain about there are far more
pseudo code:
var xhr = $.ajax blah blah async
var done = false
xhr.readyState = function(state) { if (stateIsDone) done = true}
while (!done) {
doNothing()
}
something like that? super bad
On Tue, Feb 10, 2015 at 9:51 AM, Marc Fawzi wrote:
> If readyState is async then have set a varia
If readyState is async then have set a variable in the readyState change
callback and monitor that variable in a while loop :D
What am I missing?
On Tue, Feb 10, 2015 at 9:44 AM, Elliott Sprehn
wrote:
>
>
> On Tuesday, February 10, 2015, Marc Fawzi wrote:
>
>> Here is
Async xhr with callback let's you manage the flow such that you don't do
anything until a successful response from the server. Promises make it even
nicer.
Sent from my iPhone
> On Feb 10, 2015, at 9:15 AM, George Calvert
> wrote:
>
> Ashley,
>
> Isn't it for the app dev team — rather tha
Here is a really bad idea:
Launch an async xhr and monitor its readyState in a while loop and don't exit
the loop till it has finished.
Easier than writing charged emails. Less drain on the soul.
Sent from my iPhone
> On Feb 10, 2015, at 8:48 AM, Michaela Merz wrote:
>
> No argument in rega
ke such calls less harmful.
>
> Michaela
>
>
>
> On 02/06/2015 12:28 PM, Marc Fawzi wrote:
>
> I have several 8-track tapes from the early-to-mid 70s that I'm really
> fond of. They are bigger than my iPod. Maybe I can build an adapter with
> mechanical par
I have several 8-track tapes from the early-to-mid 70s that I'm really fond
of. They are bigger than my iPod. Maybe I can build an adapter with
mechanical parts, magnetic reader and A/D convertor etc. But that's my job,
not Apple's job.
The point is, old technologies die all the time, and people w
Following this thread because there is real need for what is being
discussed.
However, until that need is satisfied, here is what we're thinking to
achieve style encapsulation, using current-world technologies, and I'm
hoping you would point out any problems you see with doing it this way.
1. We
Can someone shed light at why Scoped Style Element was removed from Chrome
experimental features?
http://caniuse.com/#feat=style-scoped
In suggesting @isolate declaration, I meant it would go inside a scoped
style element. If there are nested scope style elements and each have
@isolate then it me
If the goal is to isolate a style sheet or several per a DOM sub tree then why
not just use scoped style element that has imports that apply the stylesheet(s)
only to the sub tree in scope? Obviously, you are talking about preventing
stylesheets applied at a higher level from leaking in. So may
that's not extensible and not flexible? The
answer is most likely NO.
On Tue, Nov 18, 2014 at 11:03 PM, Florian Bösch wrote:
> On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi wrote:
>>
>> So there is no way for an unsigned script to exploit security holes in a
>> si
So there is no way for an unsigned script to exploit security holes in a
signed script?
Funny you mention crypto currencies as an idea to get inspiration
from..."Trust but verify" is detached from that... a browser can monitor
what the signed scripts are doing and if it detects a potentially malic
alicious or bad code. It only
> guarantees that the code is actually from the the certificate owner .. and
> has not been altered without the signers consent.
>
> Michaela
>
>
>
>
> On 11/19/2014 06:14 AM, Marc Fawzi wrote:
>
> "Allowing this script to run may
"Allowing this script to run may open you to all kinds of malicious attacks
by 3rd parties not associated with the party whom you're trusting."
If I give App XYZ super power to do anything, and XYZ gets
compromised/hacked then I'll be open to all sorts of attacks.
It's not an issue of party A tru
n/m ... the request is more specific than the email subject... the JS
solution to the problem is certainly less appealing than a CSS only
solution.. .will be watching this :)
On Wed, Aug 20, 2014 at 9:20 AM, Marc Fawzi wrote:
> Hmm. I thought that's part of the purpose of Web Compon
Hmm. I thought that's part of the purpose of Web Component, i.e. to
encapsulate CSS and JS? Is it not so?
On Wed, Aug 20, 2014 at 1:42 AM, Henrik Haugberg
wrote:
> I am hoping it will be possible to have root em like font size based
> values, but based on the shadow root (or host) when using sh
Probably a naive comment, but I'm curious and interested in learning since
it's one thing that's been missing from browsers:
Does your last comment mean that you'd be baking in dependency on a certain
auth standard in the user agent? What happens when the part of the
authentication model that is o
<<
We can do synchronous tests against the schema as it is feasible for
implementations to maintain a copy of the current schema for an open connection
in memory in the same thread/process as script. (Or at least, no implementer
has complained.)
>>
Oh cool. So I could have a 3rd party component
was wondering what about a synchronous .exists() (the same proposal you
had but synchronous as opposed to asynchronous)
Makes any sense?
Sent from my iPhone
> On Jun 23, 2014, at 1:28 PM, Jonas Sicking wrote:
>
>> On Mon, Jun 23, 2014 at 1:03 PM, Marc Fawzi wrote:
>> Hav
Joshua,
you're on, and I'll be happy to make suggestions once I've thought them
through... At least to some extent :)
Jonas,
<<
There is a small performance difference between them though when
applied to indexes. Indexes could have multiple entries with the same
key (but different primaryKey),
I think the same thought pattern can be applied elsewhere in the API design
for v2.
Consider the scenario of trying to find whether a given index exists or not
(upon upgradeneeded). For now, we have to write noisy code like
[].slice.call(objectStore.indexNames()).indexOf("someIndex") Why couldn't
x27;s helpful both to understand what assumptions you may be making
> (i.e. you mention a cursor; is that a critical part of your repro or is a
> simple count() enough?) and for implementors to track down actual bugs. If
> you do find browser bugs, please report them - crbug.com,
> bugzil
Hi Joshua, IDB folks,
I was about to wrap up work on a small app that uses IDB but to my absolute
surprise it looks that the number of indexed values in a MultiEntry index
is limited to 50. Maybe it's not meant to contain an infinite number but 50
seems small and arbitrary. Why not 4096? Performan
Another question about the subject
https://developers.google.com/chrome/apps/docs/developers_guide
This says that they can also run in the background, which is huge.
I'm not sure if they support content scripts like extensions and packaged
apps do. I would love to find out if the spec says anyth
Excuse my unsolicited comment here, being new to the webapps mailing list,
but here is my two cents feedback as a web developer...
I think the idea behind Web Components is good regardless of the flaws on
the spec. The idea is to create a standard built into the browser that will
allow library--an
ce with the spec.
As to continue(n) or continue(any string), i would make that
.find(something)
On Fri, May 23, 2014 at 10:41 AM, Joshua Bell wrote:
> On Fri, May 23, 2014 at 9:40 AM, marc fawzi wrote:
>
>> I thought .continue/advance was similar to the 'continue' sta
gt;
>
>
> On Wed, May 21, 2014 at 7:32 AM, Arthur Barstow wrote:
>
>> [ Bcc www-tag ; Marc - please use public-webapps for IDB discussions ]
>>
>> On 5/20/14 7:46 PM, marc fawzi wrote:
>>
>>> Hi everyone,
>>>
>>> I've been using Index
42 matches
Mail list logo
