Re: Extending createObjectUrl to MediaStream?
On Thu, Aug 29, 2013 at 3:05 AM, Robert O'Callahan rob...@ocallahan.org wrote: I can't think of any good reason to support createObjectURL(MediaStream) --- except for compatibility with existing content, which may be an issue already. As I understand it, we have the createObjectURL() design because it's easier and allows integration with systems that have a poor API story, such as CSS. I'm not a fan and wish we had avoided it altogether in favor of objects everywhere, but I lost that battle. Given that MediaStream only works for a select set of end points, not supporting createObjectURL() would be somewhat better if that's indeed feasible. -- http://annevankesteren.nl/
File API: File's name property
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/
Re: File API: File's name property
On Thu, Aug 29, 2013 at 9:48 AM, Anne van Kesteren ann...@annevk.nl 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). I don't think it makes sense to expect filenames to round-trip through File.name, especially for filenames with a broken or unknown encoding. File.name should be a best-effort at converting the platform filename to something that can be displayed to users or encoded and put in a Content-Disposition header, not an identifier for finding the file later. We may also want to restrict \ and / to leave room for using these objects in path-based contexts later. Forward slash, but not backslash. That's a platform-specific restriction. If we go down the route of limiting filenames which don't work on one or another system, the list of restrictions becomes very long. If path separators are exposed on the web, they should always be forward-slashes. -- Glenn Maynard
Re: File API: File's name property
On Thu, Aug 29, 2013 at 4:10 PM, Glenn Maynard gl...@zewt.org wrote: I don't think it makes sense to expect filenames to round-trip through File.name, especially for filenames with a broken or unknown encoding. File.name should be a best-effort at converting the platform filename to something that can be displayed to users or encoded and put in a Content-Disposition header, not an identifier for finding the file later. File has a constructor. We should be clearer about platforms too I suppose. We may also want to restrict \ and / to leave room for using these objects in path-based contexts later. Forward slash, but not backslash. That's a platform-specific restriction. If we go down the route of limiting filenames which don't work on one or another system, the list of restrictions becomes very long. If path separators are exposed on the web, they should always be forward-slashes. Given that the URL parser treats them identically, we should treat them identically everywhere else too. -- http://annevankesteren.nl/
Re: File API: File's name property
On Thu, Aug 29, 2013 at 10:14 AM, Anne van Kesteren ann...@annevk.nlwrote: On Thu, Aug 29, 2013 at 4:10 PM, Glenn Maynard gl...@zewt.org wrote: I don't think it makes sense to expect filenames to round-trip through File.name, especially for filenames with a broken or unknown encoding. File.name should be a best-effort at converting the platform filename to something that can be displayed to users or encoded and put in a Content-Disposition header, not an identifier for finding the file later. File has a constructor. We should be clearer about platforms too I suppose. All constructing a File does is give a name (and date) to a Blob. It doesn't create an association to an on-disk file, and shouldn't be restricted to filenames the local platform's filesystem can represent. Given that the URL parser treats them identically, we should treat them identically everywhere else too. URL parsing does lots of weird things that shouldn't be spread to the rest of the platform. File.name and URL parsing are completely different things, and filenames on non-Windows systems can contain backslashes. -- Glenn Maynard
Re: File API: File's name property
On Thu, Aug 29, 2013 at 4:46 PM, Glenn Maynard gl...@zewt.org wrote: All constructing a File does is give a name (and date) to a Blob. It doesn't create an association to an on-disk file, and shouldn't be restricted to filenames the local platform's filesystem can represent. Yes, but it can be submitted to a server so it has to be transformed at some point. It seems way better to do the transformation early so what you see in client-side JavaScript is similar to what you'd see in Node.js. Given that the URL parser treats them identically, we should treat them identically everywhere else too. URL parsing does lots of weird things that shouldn't be spread to the rest of the platform. File.name and URL parsing are completely different things, and filenames on non-Windows systems can contain backslashes. All the more reason to do something with it to prevent down-level bugs. -- http://annevankesteren.nl/
Re: File API: File's name property
On Thu, Aug 29, 2013 at 10:51 AM, Anne van Kesteren ann...@annevk.nlwrote: On Thu, Aug 29, 2013 at 4:46 PM, Glenn Maynard gl...@zewt.org wrote: All constructing a File does is give a name (and date) to a Blob. It doesn't create an association to an on-disk file, and shouldn't be restricted to filenames the local platform's filesystem can represent. Yes, but it can be submitted to a server so it has to be transformed at some point. It seems way better to do the transformation early so what you see in client-side JavaScript is similar to what you'd see in Node.js. It's transformed from a UTF-16 DOMString to the encoding of the protocol it's being transferred over, just like any other DOMString being sent over a non-UTF-16 protocol. URL parsing does lots of weird things that shouldn't be spread to the rest of the platform. File.name and URL parsing are completely different things, and filenames on non-Windows systems can contain backslashes. All the more reason to do something with it to prevent down-level bugs. We shouldn't prevent people in Linux from seeing their filenames because those filenames wouldn't be valid on Windows. That would require much more than just backslashes--you'd need to prevent all characters and strings that aren't valid in Windows, such as COM0. Even having non-ASCII filenames will cause problems for Windows users, since many Windows applications can only access filenames which are a subset of the user's locale (it takes extra work to use Unicode filenames in Windows). -- Glenn Maynard
Re: Extending createObjectUrl to MediaStream?
On Aug 28, 2013, at 9:48 AM, Dominique Hazael-Massieux wrote: Hi WebApps WG, The Media Capture Task Force (responsible for specs that deal with MediaStream objects [1]) has been considering whether one should be able to assign a MediaStream to video and audio elements via an URL obtained via createObjectURL or not, and is seeking feedback on the question. More precisely: A. we define a new srcObject attribute on HTMLMediaElement objects that can take directly a MediaStream object and make it playable video.srcObject = mediastream; B. the spec also supports assigning a MediaStream via the src attribute, via an URL obtained through createObjectURL: video.src = URL.createObjectURL(mediastream); While there are ongoing discussions on how to spec B properly [2] (which will require coordination with the WebApps Working Group), we are first and foremost wondering if that option is needed at all. We are thus looking for input on the use cases for createObjectURL as used for the File API, and whether these use cases would also apply to our MediaStream case. In general, is there a need for any object readable by media elements to support an URL-based approach for consistency with the rest of the platform? The fact that URL.createObjectURL exists at all is hitched to the ongoing use of strings as URLs in places like Image (img src=) and CSS. This also created the discussion about autoRevoke (namely the automatic revocation of these references), for which we added URL.createFor. As it stands, developers should bear the onus of calling URL.revokeObjectURL coupled to URL.createObjectURL, which may be a tall request. MediaStream may not be as ubiquitous as Blob, and you may be able to avoid URL strings altogether. If that's a fair assumption, option A seems like a good plan. If you go the option B route, then you'll have to also think about revocation and URL.createFor, since you'll have the same problem. On balance, I favor Option A, unless you make the case for strings :) If you choose Option B, I'm happy to work with your WG to make sure File API has the right hook for MediaStream objects, per https://www.w3.org/Bugs/Public/show_bug.cgi?id=19594 -- A* -- A*
