It's best to view RFC 2119 in the context of IETF rules for interoperability:
Progression along standards track depends on there being multiple independent
interoperable implementations of every feature.
While feature is not clearly defined, I believe that in a well-written
specification, any
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13287
Summary: Hello! Into HTML5, i need browser to browser
connection (p2p), directly! without server! Thanks.
Product: WebAppsWG
Version: unspecified
Platform: Other
URL:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13287
Ross Nicoll j...@jrn.me.uk changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sunday, July 17, 2011 1:46 PM, Jonas Sicking wrote:
On Fri, Jul 15, 2011 at 5:55 PM, Israel Hilerio isra...@microsoft.com wrote:
Jonas,
We like the concepts and principles you are proposing. It provides a more
cohesive mechanism for enforcing/supporting upgrades and it leverages the
On Mon, Jul 18, 2011 at 10:20 AM, Israel Hilerio isra...@microsoft.com wrote:
On Sunday, July 17, 2011 1:46 PM, Jonas Sicking wrote:
On Fri, Jul 15, 2011 at 5:55 PM, Israel Hilerio isra...@microsoft.com
wrote:
Jonas,
We like the concepts and principles you are proposing. It provides a
On Monday, July 11, 2011 12:46 PM, Charles Pritchard wrote:
Problem is too strong a statement. I am all for trivial changes, part of my
advocacy for getFile is from past experiences when blob was less supported;
getFile would have helped.
FileReader has base64 encoding for binary data--
On 7/18/2011 12:09 PM, Adrian Bateman wrote:
On Monday, July 11, 2011 12:46 PM, Charles Pritchard wrote:
Problem is too strong a statement. I am all for trivial changes, part of my
advocacy for getFile is from past experiences when blob was less supported;
getFile would have helped.
FileReader
The problem is around naming the binary parts attached to
multi-part-form-encoded FormData. I think I'm in favor of the more direct
solution to this problem, providing a FormData.append() variant that
optionally allows the caller to specify a name. If no name is provided and
the blob is a File,
On Monday, July 18, 2011 12:52 PM, Michael Nordman wrote:
The problem is around naming the binary parts attached to
multi-part-form-encoded
FormData. I think I'm in favor of the more direct solution to this problem,
providing a FormData.append() variant that optionally allows the caller to
2011/7/18 Michael Nordman micha...@google.com
BlobBuilder.getFile() as a solution to this particular problem is less
direct (and less obvious and less discoverable so less friendly). And it
raises questions like... Is the blob data really flattened out as a file on
the disk somewhere? If not,
2011/7/18 Adrian Bateman adria...@microsoft.com:
On Monday, July 11, 2011 12:46 PM, Charles Pritchard wrote:
Problem is too strong a statement. I am all for trivial changes, part of my
advocacy for getFile is from past experiences when blob was less supported;
getFile would have helped.
On 7/18/2011 2:42 PM, Jonas Sicking wrote:
If there is an API that replies on File to
work correctly we think we should fix it to work with Blob. For example,
FileReader is
really BlobReader and works fine with Blobs. To me, getFile() should be
unnecessary and
the best fix for FormData
On Mon, Jul 18, 2011 at 2:52 PM, Charles Pritchard ch...@jumis.com wrote:
On 7/18/2011 2:42 PM, Jonas Sicking wrote:
If there is an API that replies on File to
work correctly we think we should fix it to work with Blob. For
example, FileReader is
really BlobReader and works fine with
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13294
Summary: The send() method should fail the WebSocket connection
when data cannot be sent
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13295
Summary: The make disappear a WebSocket object case should
not fail the WebSocket connection
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
15 matches
Mail list logo
