Eric Uhrhane , 2011-02-11 15:10 -0800:
> Michael, thanks. However, I chose to use the tracker originally since
> that's what the File API was using. I'd rather not have 2 different
> places to log issues. If there's a strong reason I should move to
> Bugzilla, let me know, but otherwise I think
On Fri, Feb 11, 2011 at 4:33 AM, Michael[tm] Smith wrote:
> Eric Uhrhane , 2011-02-10 16:55 -0800:
>
>> On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson wrote:
>> > Is there somewhere that such issues should be filed?
>>
>> I'm not sure about the File API--it used to use [2], but I'm not sure
>> if i
On Fri, Feb 11, 2011 at 7:43 AM, Olli Pettay wrote:
> Hi all,
>
> the current "File API: Directories and System" seems to use
> callbacks and not events, yet other
> File APIs (the ones for read and write) use events.
> That is quite major inconsistency in the APIs.
> IIRC there was already some d
On Fri, Feb 11, 2011 at 11:38 AM, Jonas Sicking wrote:
> On Fri, Feb 11, 2011 at 11:30 AM, ben turner
> wrote:
> > It looks like I was wrong. Our current impl throws NOT_ALLOWED_ERR for
> > getting errorCode *and* result before readyState is set to DONE.
> >
> > And now that I think about it I t
On Fri, Feb 11, 2011 at 11:30 AM, ben turner wrote:
> It looks like I was wrong. Our current impl throws NOT_ALLOWED_ERR for
> getting errorCode *and* result before readyState is set to DONE.
>
> And now that I think about it I think I like that best. If we returned
> NO_ERR from errorCode before
It looks like I was wrong. Our current impl throws NOT_ALLOWED_ERR for
getting errorCode *and* result before readyState is set to DONE.
And now that I think about it I think I like that best. If we returned
NO_ERR from errorCode before DONE then it seems to imply that the
request succeeded when th
On Fri, Feb 11, 2011 at 11:16 AM, Jeremy Orlow wrote:
> On Thu, Feb 10, 2011 at 7:06 PM, ben turner wrote:
>>
>> > I think generally avoiding throwing exceptions is a good thing. So for
>> > .errorCode I would say returning unidentified or 0 is the way to go.
>>
>> I would say we should add a cod
On Thu, Feb 10, 2011 at 7:06 PM, ben turner wrote:
> > I think generally avoiding throwing exceptions is a good thing. So for
> > .errorCode I would say returning unidentified or 0 is the way to go.
>
> I would say we should add a code to IDBDatabaseException, NO_ERR = 0.
> Or else indicate someh
Hi all,
the current "File API: Directories and System" seems to use
callbacks and not events, yet other
File APIs (the ones for read and write) use events.
That is quite major inconsistency in the APIs.
IIRC there was already some discussion about which approach to use
when the API for read was d
On 11.02.2011 15:40, Kris Zyp wrote:
...
Sounds very interesting.
Did you consider making the link point to an HTML(+Script) page, and
placing the JSON object into that pages script context somehow?
Yes, I had considered that. However, I believe that most webapps that
would use this API would
On 2/11/2011 7:15 AM, Julian Reschke wrote:
> On 11.02.2011 14:48, Kris Zyp wrote:
>> Increasingly, web applications are centered around JSON-based content,
>> and utilize JavaScript to render JSON to HTML. Such applications
>> (sometimes called single page applications) frequently employ changes t
On 11.02.2011 14:48, Kris Zyp wrote:
Increasingly, web applications are centered around JSON-based content,
and utilize JavaScript to render JSON to HTML. Such applications
(sometimes called single page applications) frequently employ changes to
the hash portion of the current URL to provide back
On 2/11/2011 6:55 AM, Anne van Kesteren wrote:
> On Fri, 11 Feb 2011 14:48:26 +0100, Kris Zyp wrote:
>> Increasingly, web applications are centered around JSON-based content,
>> and utilize JavaScript to render JSON to HTML. Such applications
>> (sometimes called single page applications) frequent
On Fri, 11 Feb 2011 14:48:26 +0100, Kris Zyp wrote:
Increasingly, web applications are centered around JSON-based content,
and utilize JavaScript to render JSON to HTML. Such applications
(sometimes called single page applications) frequently employ changes to
the hash portion of the current URL
Increasingly, web applications are centered around JSON-based content,
and utilize JavaScript to render JSON to HTML. Such applications
(sometimes called single page applications) frequently employ changes to
the hash portion of the current URL to provide back/forward navigation
and bookmarkability
Eric Uhrhane , 2011-02-10 16:55 -0800:
> On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson wrote:
> > Is there somewhere that such issues should be filed?
>
> I'm not sure about the File API--it used to use [2], but I'm not sure
> if it still does.
> I've got [3] for FileWriter and [4] for FileSystem
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12032
j...@jrn.me.uk changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Wed, Feb 9, 2011 at 4:47 PM, Jeremy Orlow wrote:
> On Wed, Feb 9, 2011 at 4:00 PM, Jonas Sicking wrote:
>>
>> On Mon, Feb 7, 2011 at 3:55 PM, Jeremy Orlow wrote:
>> > On Mon, Feb 7, 2011 at 3:47 PM, Jonas Sicking wrote:
>> >>
>> >> On Sat, Feb 5, 2011 at 11:02 AM, Jeremy Orlow
>> >> wrote:
18 matches
Mail list logo
