[Bug 23147] New: Describe File API Model

2013-09-03 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23147

Bug ID: 23147
   Summary: Describe File API Model
Classification: Unclassified
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
  Assignee: a...@mozilla.com
  Reporter: a...@mozilla.com
QA Contact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org

See http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0424.html 

This includes:

1. Property clarification and
2. MIME Type clarification

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: Fwd: [XHR] request error distinction: abort and error

2013-09-03 Thread Michael[tm] Smith
The are no messages from Vitya in the public-webapps moderation queue, so I
don't know what the problem might be. I've asked the W3C systems team to
take a look.

  --Mike

Anne van Kesteren , 2013-09-03 13:15 +0100:

> For some reason Vic9's emails do not reach lists.w3.org. Mike?
> 
> -- Forwarded message --
> Date: Mon, Sep 2, 2013 at 11:49 AM
> Subject: Re: [XHR] request error distinction: abort and error
> 
> Hello, Anne van Kesteren
> 
> mailing to you directly, because somehow my letters cannot reach w3.org
> 
> http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0395.html
> 
> 
> it seems, that ESC key still can be used to abort XHR while page
> loading or with some special browsers configuration.
> Anyway, it would be nice to distinguish 3 situations:
> 1) network error;
> 2) cancellation by the user
> 3) document unloading
> in my product, i want to show the dialog with information about
> network error, but this dialog should not appear in other cases, as
> that will annoy the user.
> in my another product, i want to do retry in case of network error,
> but i should not do it in case of cancellation by the user.
> 
> Thanks

-- 
Michael[tm] Smith http://people.w3.org/mike



Re: File API: File's name property

2013-09-03 Thread Arun Ranganathan

On Sep 3, 2013, at 12:28 PM, Anne van Kesteren wrote:

> On Tue, Sep 3, 2013 at 5:14 PM, Glenn Maynard  wrote:
>> On Tue, Sep 3, 2013 at 10:17 AM, Anne van Kesteren  wrote:
>>> I don't think you want those conversion semantics for name. I do think
>>> we want the value space for names across different systems to be
>>> equivalent, which if we support zip basically means bytes.
>> 
>> I don't really understand the suggestion of using a ByteString for
>> File.name.  Can you explain how that wouldn't break
>> https://zewt.org/~glenn/picker.html, if the user picks a file named
>> "漢字.txt"?
> 
> ByteString doesn't work. A byte sequence might. If the platform does
> file names in Unicode it would be converted to bytes using utf-8.


Which in fact is how I think we should do File.name.  We'll stick to DOMString, 
but think it should specify a conversion to a byte sequence using utf-8.  And, 
restrict separators such as "/" and "\".

-- A*


Re: File API: File's name property

2013-09-03 Thread Anne van Kesteren
On Tue, Sep 3, 2013 at 5:31 PM, Arun Ranganathan  wrote:
> Which in fact is how I think we should do File.name.  We'll stick to 
> DOMString, but think it should specify a conversion to a byte sequence using 
> utf-8.  And, restrict separators such as "/" and "\".

That doesn't solve the problem I mentioned earlier for arbitrary file
names coming out of zip archives. And then your data model is not
bytes, but Unicode scalar values. We could of course accept
information loss of some kind in the conversion process between zip
archive resources and File objects and require developers to keep
track of that if they care.


-- 
http://annevankesteren.nl/



Re: File API: File's name property

2013-09-03 Thread Glenn Maynard
On Tue, Sep 3, 2013 at 11:31 AM, Arun Ranganathan  wrote:

> And, restrict separators such as "/" and "\".
>

I thought we just agreed that "\" is a platform-specific thing that
File.name shouldn't restrict.  "/" is a directory separator on just about
every platform, but "\" can appear in filenames on many systems.

On Tue, Sep 3, 2013 at 11:28 AM, Anne van Kesteren wrote:

> ByteString doesn't work. A byte sequence might. If the platform does
> file names in Unicode it would be converted to bytes using utf-8.
>

I don't know what API is being suggested that would keep File.name acting
like a String, but also allow containing arbitrary bytes.  I could imagine
one (an object that holds bytes, stringifies assuming UTF-8 and converts
from strings assuming UTF-8), but that's pretty ugly...

On Tue, Sep 3, 2013 at 11:42 AM, Anne van Kesteren wrote:

> That doesn't solve the problem I mentioned earlier for arbitrary file
> names coming out of zip archives. And then your data model is not
> bytes, but Unicode scalar values. We could of course accept
> information loss of some kind in the conversion process between zip
> archive resources and File objects and require developers to keep
> track of that if they care.
>

If you want to retain the original bytes of the filename somewhere, it
seems like it should go somewhere other than File.name.  For example, a
subclass of File, ZipFile, could contain a ByteString filenameBytes with
the original filename.  I wonder when you'd need that info, though.

By the way, in the current ZIP URL proposal, where would a File be
created?  If you use XHR to access a file inside a ZIP URL then you'd just
get a Blob, right?

-- 
Glenn Maynard


Re: File API: File's name property

2013-09-03 Thread Anne van Kesteren
On Tue, Sep 3, 2013 at 5:54 PM, Glenn Maynard  wrote:
> On Tue, Sep 3, 2013 at 11:31 AM, Arun Ranganathan  wrote:
>> And, restrict separators such as "/" and "\".
>
> I thought we just agreed that "\" is a platform-specific thing that
> File.name shouldn't restrict.  "/" is a directory separator on just about
> every platform, but "\" can appear in filenames on many systems.

The problem is that once you put it through the URL parser it'll
become "/". And I suspect given directory APIs and such it'll go
through that layer at some point.


> On Tue, Sep 3, 2013 at 11:28 AM, Anne van Kesteren  wrote:
>>
>> ByteString doesn't work. A byte sequence might. If the platform does
>> file names in Unicode it would be converted to bytes using utf-8.
>
> I don't know what API is being suggested that would keep File.name acting
> like a String, but also allow containing arbitrary bytes.  I could imagine
> one (an object that holds bytes, stringifies assuming UTF-8 and converts
> from strings assuming UTF-8), but that's pretty ugly...

Well, my suggestion was rawName and name (which would have loss of
information), per the current zip archive API design.


> By the way, in the current ZIP URL proposal, where would a File be created?
> If you use XHR to access a file inside a ZIP URL then you'd just get a Blob,
> right?

There's an API too.


-- 
http://annevankesteren.nl/



Re: File API: lacks model

2013-09-03 Thread Anne van Kesteren
On Tue, Sep 3, 2013 at 3:07 PM, Arun Ranganathan  wrote:
> This feedback is a bit vague.

Does http://the-pastry-box-project.net/anne-van-kesteren/2013-september-2/
help illustrate it a bit?


>> I think you should describe the underlying model for Blob/File so
>> other specifications can more easily hook into it. E.g. if I want to
>> represent a File object with a name /x/ and type /y/ there's not a
>> clear way to do that right now. This also leads to issues such as [value 
>> space of properties]
>
> Why isn't there a clear way to do that now?

Say I define an API for zip archives and provide an API to get a File
object out of a zip archive. I suppose I could define the relevant
conversions to the attribute values, but it seems there should be an
underlying abstract concept of a file that the File API reflects and
operates on (and other APIs can operate on too).


>> E.g. "A |blob| provides asynchronous access to a byte sequence. A blob
>> has an associated |type| which is a MIME type." (Which could be a link
>> to the variant of MIME type you use.) And then you build the API on
>> top of this model.
>
> I treat http://mimesniff.spec.whatwg.org/ as relatively normative here.  What 
> am I missing?

Mostly that there's no abstract concept of a blob, just an API.
(There's also that mimesniff treats types as a byte sequence, whereas
your specification talks about it as both a byte sequence
(ASCII-encoded string) and string (empty string).


-- 
http://annevankesteren.nl/



Re: File API: File's name property

2013-09-03 Thread Anne van Kesteren
On Tue, Sep 3, 2013 at 5:14 PM, Glenn Maynard  wrote:
> On Tue, Sep 3, 2013 at 10:17 AM, Anne van Kesteren  wrote:
>> I don't think you want those conversion semantics for name. I do think
>> we want the value space for names across different systems to be
>> equivalent, which if we support zip basically means bytes.
>
> I don't really understand the suggestion of using a ByteString for
> File.name.  Can you explain how that wouldn't break
> https://zewt.org/~glenn/picker.html, if the user picks a file named
> "漢字.txt"?

ByteString doesn't work. A byte sequence might. If the platform does
file names in Unicode it would be converted to bytes using utf-8.


-- 
http://annevankesteren.nl/



Re: File API: File's name property

2013-09-03 Thread Glenn Maynard
On Tue, Sep 3, 2013 at 9:03 AM, Arun Ranganathan  wrote:

> It wouldn't be wise to restrict '/' or '\' or try to delve too deep into
> platform land BUT the FileSystem API introduces directory syntax which
> might make being lax a fly in the ointment for later.
>

I wouldn't object to restricting "/" if it'll make other APIs more
sensible.  Every platform I've used treats it as a separator.

On Tue, Sep 3, 2013 at 10:17 AM, Anne van Kesteren wrote:

> I don't think you want those conversion semantics for name. I do think
> we want the value space for names across different systems to be
> equivalent, which if we support zip basically means bytes.


I don't really understand the suggestion of using a ByteString for
File.name.  Can you explain how that wouldn't break
https://zewt.org/~glenn/picker.html, if the user picks a file named
"漢字.txt"?

-- 
Glenn Maynard


Re: File API: File's name property

2013-09-03 Thread Anne van Kesteren
On Tue, Sep 3, 2013 at 3:03 PM, Arun Ranganathan  wrote:
> Well, https://www.w3.org/Bugs/Public/show_bug.cgi?id=23138 is to make the 
> 'type' attribute a ByteString.  Is that your request here for the name 
> attribute as well?

I don't think you want those conversion semantics for name. I do think
we want the value space for names across different systems to be
equivalent, which if we support zip basically means bytes. This could
mean accepting DOMString and then doing the conversion yourself
through utf-8. However, it's not very clear to me how to do the
conversion back in a way that minimizes information loss and works
everywhere compatibly. For zip archives I ended up with rawPath
(bytes) and path (bytes converted to a string using utf-8 and vice
versa). Maybe we should use that model here too?


> It wouldn't be wise to restrict '/' or '\' or try to delve too deep into 
> platform land BUT the FileSystem API introduces directory syntax which might 
> make being lax a fly in the ointment for later.

Right. Zip archives also have paths and it would be annoying if we ran
into problems there.


-- 
http://annevankesteren.nl/



[Bug 23140] New: Further Boundary Checking is Necessary on Slice Calls

2013-09-03 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23140

Bug ID: 23140
   Summary: Further Boundary Checking is Necessary on Slice Calls
Classification: Unclassified
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
  Assignee: a...@mozilla.com
  Reporter: a...@mozilla.com
QA Contact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org

https://bugzilla.mozilla.org/show_bug.cgi?id=906413 showcases a slice call on a
Blob of size 4 of the sort:

slice(0, Number.MAX_SIZE) 

on which on Fx returns a Blob of size 0, but only because of the 'long long'
threshold being reached.

This bug is to introduce further boundary checks on slice calls, disallowing a
slice bigger than the original blob for example.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: File API: lacks model

2013-09-03 Thread Arun Ranganathan
Anne, 

This feedback is a bit vague. 


> I think you should describe the underlying model for Blob/File so
> other specifications can more easily hook into it. E.g. if I want to
> represent a File object with a name /x/ and type /y/ there's not a
> clear way to do that right now. This also leads to issues such as [value 
> space of properties]


Why isn't there a clear way to do that now?  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23138 notwithstanding, you can 
either obtain a File from the underlying file system with a "best guess" type 
by the UA, OR create one with a constructor.  What's missing exactly?


> E.g. "A |blob| provides asynchronous access to a byte sequence. A blob
> has an associated |type| which is a MIME type." (Which could be a link
> to the variant of MIME type you use.) And then you build the API on
> top of this model.
> 

I treat http://mimesniff.spec.whatwg.org/ as relatively normative here.  What 
am I missing?

-- A*


Re: File API: File's name property

2013-09-03 Thread Arun Ranganathan
Well, https://www.w3.org/Bugs/Public/show_bug.cgi?id=23138 is to make the 
'type' attribute a ByteString.  Is that your request here for the name 
attribute as well?

It wouldn't be wise to restrict '/' or '\' or try to delve too deep into 
platform land BUT the FileSystem API introduces directory syntax which might 
make being lax a fly in the ointment for later.


On Aug 29, 2013, at 10:48 AM, Anne van Kesteren wrote:

> As currently specified File's name property seems to be a code unit
> sequence. In zip archives the resource's path is a byte sequence. I
> don't really know what popular file systems do. Given that a File has
> to be transmitted over the wire now and then, including it's name
> property value, a code unit sequence seems like the wrong type. It
> would at least lead to information loss which I'm not sure is
> acceptable if we can prevent it (or at least make it more obvious that
> it is going on, by doing a transformation early on).
> 
> We may also want to restrict "\" and "/" to leave room for using these
> objects in path-based contexts later.
> 
> 
> -- 
> http://annevankesteren.nl/
> 




[Bug 23138] New: Make type a ByteString

2013-09-03 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23138

Bug ID: 23138
   Summary: Make type a ByteString
Classification: Unclassified
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
  Assignee: a...@mozilla.com
  Reporter: a...@mozilla.com
QA Contact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org

Bug 23106 suggests that since 'type' attribute is used over HTTP and parsed
like Content-Type, it should be a ByteString.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Anne van Kesteren
On Tue, Sep 3, 2013 at 2:01 PM, Robert O'Callahan  wrote:
> Yes. For example there are plans to enable some kind of "private mode" for
> WebRTC MediaStreams that protects stream contents from inspection by the
> page. I don't know exactly how this is going to work, but if we allow
> MediaStreams to span domains it may get more complicated.

This scenario sounds very different from the one you outline next.


> More concretely,
> in Gecko we have experimental code to pipe HTML media element output into
> MediaStreams, so we already tag MediaStream data with origin information,
> but it's implemented in such a way that getUserMedia from one domain would
> be restricted in another domain (the other domain could render it in a media
> element, but it would be treated as cross-origin and thus would taint
> canvases it's drawn into, for example).

It's not clear why if as a page I decide to share the MediaStream
object I would not want all of that to be shared as I could share all
of that regardless, it'd just require more hoops to jump through.


> I think it may make sense to provide cross-origin MediaStream transfer at
> some point in the future, but I think we have more important things to work
> on first.

Again, what I'm trying to understand is why we have origin ties in the
first place. So far no objects carry origin information in this
regard.


-- 
http://annevankesteren.nl/



Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Robert O'Callahan
On Wed, Sep 4, 2013 at 12:31 AM, Anne van Kesteren  wrote:

> On Tue, Sep 3, 2013 at 1:25 PM, Robert O'Callahan 
> wrote:
> > The widget would not only have to be written by a third party, but
> actually
> > hosted on their domain. And not just optionally, but for some reason the
> > widget provider has decided not to allow the author to host it on their
> own
> > domain.
>
> That's fairly common though, consider eg YouTube.
>

Youtube hosts embedded players because they're playing Youtube's content,
not because Youtube's widget is particularly special. If you just want an
HTML5 video player app to wrap around your own content, you don't use
Youtube and you host it yourself.

> Sure, it could happen, but it seems somewhat far-fetched to me. On the
> other
> > hand, allowing MediaStream graphs to span domains could have potentially
> > far-reaching consequences. I don't see any need to rush into this.
>
> It's not entirely clear to me what you mean by this. Are these
> concerns specific to MediaStream and not applicable to Blob?
>

Yes. For example there are plans to enable some kind of "private mode" for
WebRTC MediaStreams that protects stream contents from inspection by the
page. I don't know exactly how this is going to work, but if we allow
MediaStreams to span domains it may get more complicated. More concretely,
in Gecko we have experimental code to pipe HTML media element output into
MediaStreams, so we already tag MediaStream data with origin information,
but it's implemented in such a way that getUserMedia from one domain would
be restricted in another domain (the other domain could render it in a
media element, but it would be treated as cross-origin and thus would taint
canvases it's drawn into, for example).

I think it may make sense to provide cross-origin MediaStream transfer at
some point in the future, but I think we have more important things to work
on first.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*


Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Anne van Kesteren
On Tue, Sep 3, 2013 at 1:25 PM, Robert O'Callahan  wrote:
> The widget would not only have to be written by a third party, but actually
> hosted on their domain. And not just optionally, but for some reason the
> widget provider has decided not to allow the author to host it on their own
> domain.

That's fairly common though, consider eg YouTube.


> Sure, it could happen, but it seems somewhat far-fetched to me. On the other
> hand, allowing MediaStream graphs to span domains could have potentially
> far-reaching consequences. I don't see any need to rush into this.

It's not entirely clear to me what you mean by this. Are these
concerns specific to MediaStream and not applicable to Blob?


-- 
http://annevankesteren.nl/



Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Robert O'Callahan
On Tue, Sep 3, 2013 at 6:31 PM, Anne van Kesteren  wrote:

> On Tue, Sep 3, 2013 at 12:29 AM, Robert O'Callahan 
> wrote:
> > What are your use-cases where they're not the same? More importantly,
> what
> > are the use-cases where they cannot be made the same by the developer?
>
> E.g. embedding a widget for video or audio manipulation. The widget
> could be written by a third-party of sorts.
>

The widget would not only have to be written by a third party, but actually
hosted on their domain. And not just optionally, but for some reason the
widget provider has decided not to allow the author to host it on their own
domain.

Sure, it could happen, but it seems somewhat far-fetched to me. On the
other hand, allowing MediaStream graphs to span domains could have
potentially far-reaching consequences. I don't see any need to rush into
this.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*


[Bug 22958] "The parameter's value must be 'utf-8'"

2013-09-03 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22958

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ann...@annevk.nl
 Resolution|--- |INVALID

--- Comment #3 from Anne  ---
That requirement is a conformance requirement, not a processing requirement.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 22958] "The parameter's value must be 'utf-8'"

2013-09-03 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22958

Robin Berjon  changed:

   What|Removed |Added

 CC||public-webapps@w3.org,
   ||ro...@w3.org
  Component|HTML5 spec  |Server-Sent Events (editor:
   ||Ian Hickson)
   Assignee|dave.n...@w3.org|i...@hixie.ch
Product|HTML WG |WebAppsWG
 QA Contact|public-html-bugzi...@w3.org |public-webapps-bugzilla@w3.
   ||org

--- Comment #2 from Robin Berjon  ---
Moving to WebApps

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Fwd: [XHR] request error distinction: abort and error

2013-09-03 Thread Anne van Kesteren
For some reason Vic9's emails do not reach lists.w3.org. Mike?

-- Forwarded message --
Date: Mon, Sep 2, 2013 at 11:49 AM
Subject: Re: [XHR] request error distinction: abort and error

Hello, Anne van Kesteren

mailing to you directly, because somehow my letters cannot reach w3.org

http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0395.html


it seems, that ESC key still can be used to abort XHR while page
loading or with some special browsers configuration.
Anyway, it would be nice to distinguish 3 situations:
1) network error;
2) cancellation by the user
3) document unloading
in my product, i want to show the dialog with information about
network error, but this dialog should not appear in other cases, as
that will annoy the user.
in my another product, i want to do retry in case of network error,
but i should not do it in case of cancellation by the user.

Thanks



Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Stefan Håkansson LK
On 2013-09-03 14:02, Anne van Kesteren wrote:
> On Tue, Sep 3, 2013 at 12:48 PM, Stefan Håkansson LK
>  wrote:
>> I think it should stop playing since the object srcObject references is
>> gone. (It would work differently with createObjecURL + myVideoTag.src
>> since that would only be a handle to an underlying resource)
>
> The object is not gone, it's neutered. That could mean e.g. that
> instead you'd get black and no sound. Kinda depends on how you define
> a neutered MediaStream to work.

Right. I should've known. Thanks.

>
>




Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Anne van Kesteren
On Tue, Sep 3, 2013 at 12:48 PM, Stefan Håkansson LK
 wrote:
> I think it should stop playing since the object srcObject references is
> gone. (It would work differently with createObjecURL + myVideoTag.src
> since that would only be a handle to an underlying resource)

The object is not gone, it's neutered. That could mean e.g. that
instead you'd get black and no sound. Kinda depends on how you define
a neutered MediaStream to work.


-- 
http://annevankesteren.nl/



Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse

2013-09-03 Thread Anne van Kesteren
On Tue, Sep 3, 2013 at 9:18 AM, Takeshi Yoshino  wrote:
> In the spec, we have three "cancel"s
> - cancel an instance of fetch algorithm
> - cancel network activity

These are the same. Attempted to clarify.


> - cancel a request

This is the end user terminate, correct?


> The spec says "Cancel a request" is an abort error which fires events in
> XHR-XHRUpload order, but abort() fires events in XHR-XHRUpload order. It was
> confusing so I filed this bug. First and at least, I'd like to make this
> clear.
>
> What does "cancel a request" correspond to?
>
> Re: loadstart, I don't have strong opinion, too.

I aligned abort() with end user abort now. Would you like to be
acknowledged as "Takeshi Yoshino"? If you can give me your name in
kanji I can include that too. See e.g.
http://encoding.spec.whatwg.org/#acknowledgments for some examples.

See http://xhr.spec.whatwg.org/ for the updated text. And
https://github.com/whatwg/xhr/commits for an overview of the changes.


-- 
http://annevankesteren.nl/



Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Stefan Håkansson LK
On 2013-09-03 12:01, Harald Alvestrand wrote:
> On 09/03/2013 10:27 AM, Stefan Håkansson LK wrote:
>> On 2013-09-03 01:29, Robert O'Callahan wrote:
>>> What are your use-cases where they're not the same? More importantly,
>>> what are the use-cases where they cannot be made the same by the developer?
>> E.g. the main page delegating communication to someone else (perhaps via
>> an iFrame). If the MediaStream is a transferable object the incoming
>> MediaStream can be transferred to the main page, which in turn can
>> control layout and rendering.
>
> One interesting thing about a MediaStream is that it's got multiple
> links to the world around it. In particular, it can be connected to
> multiple downstream objects.
> This means that what happens to its peers when one transfers it has to
> be defined.
>
> For instance, if MediaStream were transferable, could I do this?
>
> GetUserMedia(., success, failure)
>
> function success(stream) {
>  myVideoTag.srcObject = stream
>  stream.transfer(myWorker)
> }
>
> and after this - would the video stop playing (because the stream is
> gone from my context), or not?

I think it should stop playing since the object srcObject references is 
gone. (It would work differently with createObjecURL + myVideoTag.src 
since that would only be a handle to an underlying resource)

If you'd like it to continue playing you'd have to clone the MediaStream 
and transfer the clone.

>
>
>




[Bug 23102] Reset response entity bodies

2013-09-03 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23102

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Anne  ---
https://github.com/whatwg/xhr/commit/459fa4a4748f3731894a31675056efc975539c94

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Harald Alvestrand

On 09/03/2013 10:27 AM, Stefan Håkansson LK wrote:

On 2013-09-03 01:29, Robert O'Callahan wrote:

What are your use-cases where they're not the same? More importantly,
what are the use-cases where they cannot be made the same by the developer?

E.g. the main page delegating communication to someone else (perhaps via
an iFrame). If the MediaStream is a transferable object the incoming
MediaStream can be transferred to the main page, which in turn can
control layout and rendering.


One interesting thing about a MediaStream is that it's got multiple 
links to the world around it. In particular, it can be connected to 
multiple downstream objects.
This means that what happens to its peers when one transfers it has to 
be defined.


For instance, if MediaStream were transferable, could I do this?

GetUserMedia(., success, failure)

function success(stream) {
   myVideoTag.srcObject = stream
   stream.transfer(myWorker)
}

and after this - would the video stop playing (because the stream is 
gone from my context), or not?





Re: Extending createObjectUrl to MediaStream?

2013-09-03 Thread Stefan Håkansson LK
On 2013-09-03 01:29, Robert O'Callahan wrote:
> What are your use-cases where they're not the same? More importantly,
> what are the use-cases where they cannot be made the same by the developer?

E.g. the main page delegating communication to someone else (perhaps via 
an iFrame). If the MediaStream is a transferable object the incoming 
MediaStream can be transferred to the main page, which in turn can 
control layout and rendering.

>
> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny
> eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha
> iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e
> tfaokreg iyvoeunr, 'm aotr  atnod sgaoy ,h o'mGee.t"  uTph eann dt hwea
> lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w *
> *




Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse

2013-09-03 Thread Takeshi Yoshino
On Fri, Aug 2, 2013 at 2:13 AM, Anne van Kesteren  wrote:

> On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino 
> wrote:
> > Change on 2010/09/13
> >
> http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/Overview.src.html.diff?r1=1.138;r2=1.139;f=h
> > reversed the order of event firing for "request error" algorithm and
> send()
> > method to XHRUpload-then-XHR.
> >
> > send() (only loadstart event) and abort() method are still specified to
> fire
> > events in XHR-then-XHRUpload order. Is this intentional or we should make
> > them consistent?
>
> We should make them consistent in some manner. Firing on the main
> object last makes sense to me. It also makes some amount of conceptual
> sense to do the reverse for when the fetching starts, but I feel less
> strongly about that.


In the spec, we have three "cancel"s
- cancel an instance of fetch algorithm
- cancel network activity
- cancel a request

The spec says "Cancel a request" is an abort error which fires events in
XHR-XHRUpload order, but abort() fires events in XHR-XHRUpload order. It
was confusing so I filed this bug. First and at least, I'd like to make
this clear.

What does "cancel a request" correspond to?

Re: loadstart, I don't have strong opinion, too.