On Wed, 07 May 2008 15:39:01 +0200, Charles McCathieNevile
<[EMAIL PROTECTED]> wrote:
Opera has a proposal for a specification that would revive (and
supersede) the file upload API that has been lingering so long as a
work item.
...
A draft is at http://dev.w3.org/2006/webapi/fileio/fil
On Tue, 13 May 2008, Maciej Stachowiak wrote:
> On May 13, 2008, at 5:08 AM, Charles McCathieNevile wrote:
> >
> > (I suspect that if we are still relying on a thing called 'blob'
> > because we still don't have real file system access with some sense of
> > security by the time we want to hand
On May 13, 2008, at 5:08 AM, Charles McCathieNevile wrote:
On Sun, 11 May 2008 05:10:57 +0200, Aaron Boodman <[EMAIL PROTECTED]>
wrote:
On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
... I'm not really clear on why Blobs must be distinct from
ByteArrays.
On Sun, 11 May 2008 05:10:57 +0200, Aaron Boodman <[EMAIL PROTECTED]> wrote:
On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
... I'm not really clear on why Blobs must be distinct from ByteArrays.
As I read it, the Blob proposal also explicitly ties in a bit of
On Mon, 12 May 2008 07:40:44 +0200, Chris Prince <[EMAIL PROTECTED]>
wrote:
On Sun, May 11, 2008 at 9:22 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
On Sun, May 11, 2008 at 6:46 PM, Maciej Stachowiak
> Open question: can a File be stored in a SQL database? If
> so, does the database sto
On Sun, May 11, 2008 at 9:22 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
> On Sun, May 11, 2008 at 6:46 PM, Maciej Stachowiak
>
> > Open question: can a File be stored in a SQL database? If
> > so, does the database store the data or a reference (such as a path or Mac
> > OS X Alias)?
>
> The
On Sun, May 11, 2008 at 6:46 PM, Maciej Stachowiak
>> It seems better if the read API is just async for this case to prevent
>> the problem.
>
> It can't entirely prevent the problem. If you read a big enough chunk, it
> will cause swapping which hits the disk just as much as file reads. Possibly
On May 11, 2008, at 6:01 PM, Aaron Boodman wrote:
On Sun, May 11, 2008 at 5:46 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
Well, that depends on how good the OS buffer cache is at
prefetching. But in
general, there would be some disk access.
It seems better if the read API is just a
On Sun, May 11, 2008 at 5:46 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> Well, that depends on how good the OS buffer cache is at prefetching. But in
> general, there would be some disk access.
It seems better if the read API is just async for this case to prevent
the problem.
>> I see wh
On May 11, 2008, at 4:40 PM, Aaron Boodman wrote:
On Sun, May 11, 2008 at 4:22 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
Here's one additional question on how this would work with
ByteArray.
The read API for ByteArray is currently synchronous. Doesn't this
mean
that with large fil
On Sun, May 11, 2008 at 4:22 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>> Here's one additional question on how this would work with ByteArray.
>> The read API for ByteArray is currently synchronous. Doesn't this mean
>> that with large files accessing bytearray[n] could block?
>
> If the B
On May 11, 2008, at 4:08 PM, Aaron Boodman wrote:
On Sun, May 11, 2008 at 3:02 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
Both of these can be addressed by the APIs (including the worker
transfer
mechanism) making a copy, which can use a copy-on-write mechanism
to avoid
actually ma
On Sun, May 11, 2008 at 3:02 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> Both of these can be addressed by the APIs (including the worker transfer
> mechanism) making a copy, which can use a copy-on-write mechanism to avoid
> actually making a copy in the common case.
Ok, so just so I'm cl
On May 10, 2008, at 11:39 PM, Chris Prince wrote:
On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
I'm not really clear on why Blobs must be distinct from ByteArrays.
The only explanation is: "The primary difference is that Blobs are
immutable*, and can therefo
Responses to several of the comments so far:
On Fri, May 9, 2008 at 9:15 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> I'm not sure I like the way that the bytes are made accessible, but
> that's a minor detail really.
I tend to agree. The 'Creating Blobs' section and the readAs*()
methods were
On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> I really like the idea of adding consistent APIs for binary data in the many
> places in the Web platform that need them. However, I'm not really clear on
> why Blobs must be distinct from ByteArrays. The only explanat
On Sun, 11 May 2008, Charles McCathieNevile wrote:
>
> > Do we have the resources to have someone champion this spec?
>
> Are you asking the WG, or Google?
The Web community as a whole. I don't care which working group (if any)
"owns" it, and I don't have any reason to prefer that Google work
On Sat, 10 May 2008 06:15:01 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Wed, 7 May 2008, Aaron Boodman wrote:
The Gears team has also been putting together a proposal for file access
which overlaps in some ways with Opera's, but is also orthogonal in some
ways:
http://code.google.com/
On May 7, 2008, at 10:08 PM, Aaron Boodman wrote:
Hi everyone,
Opera has a proposal for a specification that would revive (and
supersede)
the file upload API that has been lingering so long as a work item.
The Gears team has also been putting together a proposal for file
access which ov
On Wed, 7 May 2008, Aaron Boodman wrote:
> Charles wrote:
> > Opera has a proposal for a specification that would revive (and
> > supersede) the file upload API that has been lingering so long as a
> > work item.
I would echo the other comments people have made regarding the security
model bei
On May 8, 2008, at 1:18 AM, Arve Bersvendsen wrote:
On Wed, 07 May 2008 20:57:25 +0100, Maciej Stachowiak
<[EMAIL PROTECTED]> wrote:
They both said that this proposal was only meant for things like
widgets, and agreed with my assessment that it would be a giant
security hole if exposed
On Wed, 07 May 2008 20:57:25 +0100, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
They both said that this proposal was only meant for things like
widgets, and agreed with my assessment that it would be a giant security
hole if exposed to web content.
Without commenting further: Yes, in
Hi everyone,
> Opera has a proposal for a specification that would revive (and supersede)
> the file upload API that has been lingering so long as a work item.
The Gears team has also been putting together a proposal for file
access which overlaps in some ways with Opera's, but is also
orthogona
Scott Shattuck wrote:
I'm not trying to be difficult, far from it. I'm just trying to truly
understand where you see things headed in this regard.
It's still in flux, but there's a general goal to not have ways for sites to
have expanded privileges. If you have use cases that require those,
is
this really cool new Java bridge (6u10/plugin2), that allows seamless
integration of scriptable Java code in any Web application. And there
is this almost endless list of available extensions.. File IO, Socket
API, XHR with event-based parsing and no-same-host, mpeg, MIDI,
Address-book,
On May 7, 2008, at 1:33 PM, Boris Zbarsky wrote:
Scott Shattuck wrote:
1) The script is running at a file:// URI
I believe it's key that future specification work keep in mind that
this isn't the rare case it used to be, it's one definition of "run
offline".
While true, note that Gecko
Hey Chaals,
On May 7, 2008, at 10:39 AM, Charles McCathieNevile wrote:
On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak
<[EMAIL PROTECTED]> wrote:
Yep. That's the idea.
Here are some of the more obvious security issues:
[several obviously interesting things]
6) Despite clearly hav
Scott Shattuck wrote:
1) The script is running at a file:// URI
I believe it's key that future specification work keep in mind that this
isn't the rare case it used to be, it's one definition of "run offline".
While true, note that Gecko also supports actual running offline of http URIs,
On May 7, 2008, at 1:14 PM, Boris Zbarsky wrote:
Scott Shattuck wrote:
This is possible today on IE and Mozilla with a single user-visible
security prompt.
That's only the case in Mozilla if:
1) The script is running at a file:// URI
I believe it's key that future specification work k
Scott Shattuck wrote:
This is possible today on IE and Mozilla with a single user-visible
security prompt.
That's only the case in Mozilla if:
1) The script is running at a file:// URI
or
2) The user has changed a hidden preference to allow random
sites to put up this prompt.
or
3)
On May 7, 2008, at 9:47 AM, Maciej Stachowiak wrote:
On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote:
Hi folks,
Opera has a proposal for a specification that would revive (and
supersede)
the file upload API that has been lingering so long as a work item.
In a nutshell, it pr
Charles McCathieNevile wrote:
On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote:
Hi folks,
Opera has a proposal for a specification that would revive (and
supersede)
the file upload API that has be
On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote:
Hi folks,
Opera has a proposal for a specification that would revive (and
supersede)
the file upload API that has been lingering so long as a work
On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote:
Hi folks,
Opera has a proposal for a specification that would revive (and
supersede)
the file upload API that has been lingering so long as a work item.
In a nutshell, it provides the ability for a web application to get a
filespa
Hi folks,
Opera has a proposal for a specification that would revive (and supersede)
the file upload API that has been lingering so long as a work item.
In a nutshell, it provides the ability for a web application to get a
filespace, by asking the user to identify such a space, and making it
av
35 matches
Mail list logo
