I read quickly the thread but it seems like this is exactly the issue I
had doing [1].
The use case was just decoding utf-8 html chunked buffers and modifying
the content on the fly to stream it somewhere else.
It had to work inside browsers and with node (which as far as I know
does not
Le 21/08/2013 19:03, Jonas Sicking a écrit :
On Tue, Aug 20, 2013 at 4:13 PM, Aymeric Vitte vitteayme...@gmail.com wrote:
The specs says :
It can also return partial Blob data. Partial Blob data is the part of the
File or Blob that has been read into memory currently; when processing
Le 21/08/2013 16:16, Arun Ranganathan a écrit :
On Aug 20, 2013, at 7:13 PM, Aymeric Vitte wrote:
The specs says :
It can also return /partial Blob data/. Partial Blob data is the
part of the |File| http://www.w3.org/TR/FileAPI/#dfn-file or |Blob|
http://www.w3.org/TR/FileAPI/#dfn-Blob
on a streaming style, I will watch the API handling
incremental data but I still don't get the use of the partial blob as it
is in the spec.
Regards
Aymeric
Le 22/08/2013 01:21, Jonas Sicking a écrit :
On Wed, Aug 21, 2013 at 3:56 PM, Aymeric Vitte vitteayme...@gmail.com wrote:
Combination
Le 22/08/2013 09:28, Jonas Sicking a écrit :
Does anyone have examples of code that uses the Node.js API? I'd love
to look at how people practically end up consuming data?
I am doing something like this:
var parse=function() {
//process this.stream_
this.queue_.shift();
if
The Streams API says for now This event handler should mimic the
|FileReader.onprogress|
http://dev.w3.org/2006/webapi/FileAPI/#dfn-onprogress event handler
The second proposal is not very explicit for now but there is a read
resolver.
This discussion seems to be the same as the Overlap
/2013 01:25, Aymeric Vitte a écrit :
The Streams API says for now This event handler should mimic the
|FileReader.onprogress|
http://dev.w3.org/2006/webapi/FileAPI/#dfn-onprogress event
handler
The second proposal is not very explicit for now but there is a read
resolver.
This discussion
Apparently we are not talking about the same thing, while I am thinking
to a high level interface your interface is taking care of the
underlying level.
Like node's streams, node had to define it since it was not existing
(but is someone using node's streams as such or does everybody use the
, why?
Regards
Aymeric
Le 12/09/2013 20:36, Takeshi Yoshino a écrit :
On Thu, Sep 12, 2013 at 10:58 PM, Aymeric Vitte
vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote:
Apparently we are not talking about the same thing, while I am
thinking to a high level interface your
)
How can you get the data another way?
Regards,
Aymeric
Le 13/09/2013 06:36, Takeshi Yoshino a écrit :
On Fri, Sep 13, 2013 at 5:15 AM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
Isaac said too So, just to be clear, I'm **not** suggesting that
browser
Le 13/09/2013 14:23, Takeshi Yoshino a écrit :
On Fri, Sep 13, 2013 at 6:08 PM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
Now you want a stream interface so you can code some js like
mspack on top of it.
I am still missing a part of the puzzle
Le 13/09/2013 15:11, Takeshi Yoshino a écrit :
On Fri, Sep 13, 2013 at 9:50 PM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
Le 13/09/2013 14:23, Takeshi Yoshino a écrit :
Do you mean that those data producer APIs should be changed to
provide read
Did you see
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0593.html ?
Attempt to find a link between the data producers APIs and a Streams API
like yours.
Regards
Aymeric
Le 20/09/2013 15:16, Takeshi Yoshino a écrit :
On Sat, Sep 14, 2013 at 12:03 AM, Aymeric Vitte
Le 24/09/2013 21:24, Takeshi Yoshino a écrit :
On Wed, Sep 25, 2013 at 12:41 AM, Aymeric Vitte
vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote:
Did you see
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0593.html
?
Yes. This example seems to be showing
Looks good, comments/questions :
- what's the use of readEncoding?
- StreamReadType: add MediaStream? (and others if existing)
- would it be possible to pipe from StreamReadType to other StreamReadType?
- would it be possible to pipe from a source to different targets (my
example of
I am still not very familiar with promises, but if I take your
preceeding example:
var sourceStream = xhr.response;
var resultStream = new Stream();
var fileWritingPromise = fileWriter.write(resultStream);
var encryptionPromise = crypto.subtle.encrypt(aesAlgorithmEncrypt,
aesKey, sourceStream,
I think the plan should be more here now:
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html
Regards
Aymeric
Le 02/10/2013 18:32, Arthur Barstow a écrit :
Hi Feras,
If any of the data for the Streams API spec in [PubStatus] is not
accurate, please provide corrections.
Should this not be synchronized with the Streams API? Please see recent
evolutions [1] and thread [2] (where WebRTC streams are mentioned)
Ccing Webapps and Takeshi/Feras.
Regarding your proposal I was about to propose to add about the same
thing in Streams: at least a stop method (which
Le 18/10/2013 19:31, Stefan Håkansson LK a écrit :
I think we're talking about completely different streams, and what Adam
is proposing is applicable for MediaStreamTracks in the context of a
WebRTC PeerConnection.
I don't see why, a stream is a stream, this would be strange that a
Streams API
Le 18/10/2013 19:13, Adam Roach a écrit :
To be clear, the .enabled flag and .stop() method are already there,
and they already pause/unpause the stream and tear it down,
respectively. I'm just proposing concrete semantics for how they
interact with any PeerConnection that the track is
What I am saying here is that there should be an unique and unified
Streams API supported by all related APIs, each group where it is
relevant should feel concerned instead of thinking another one might be.
Le 18/10/2013 20:04, Adam Roach a écrit :
On 10/18/13 12:47, Aymeric Vitte wrote:
Le
to do a precise flow
control, and for existing APIs like WebSockets it's not easy to control
the flow and avoid in some situations to overload the UA.
Regards,
Aymeric
Le 21/10/2013 13:14, Takeshi Yoshino a écrit :
Sorry for blank of ~2 weeks.
On Fri, Oct 4, 2013 at 5:57 PM, Aymeric Vitte
I have suggested some additions/changes in my latest reply to the
Overlap thread.
The list of streams producers/consumers is not final but obviously
WebSockets are missing.
Who is coordinating each group that should get involved? MediaStream for
example should be based on the Stream
As you mention streams are existing since the begining of times and it's
incredible that this does not exist on a web platform, but apparently
the subject is still not so easy, node changed its stream quite a lot of
time.
I probably will not be able to answer back in the coming days but your
for the structured clone algo, and this is missing.
Regards
Aymeric
Le 03/11/2013 19:02, Arthur Barstow a écrit :
Hi Aymeric,
On 10/29/13 7:22 AM, ext Aymeric Vitte wrote:
Who is coordinating each group that should get involved?
I thought you agreed to do that ;).
MediaStream for example should
not be, uses cases are real (myself but I am not the only one)
Regards,
Aymeric
Le 30/10/2013 12:49, Takeshi Yoshino a écrit :
On Wed, Oct 30, 2013 at 8:14 PM, Takeshi Yoshino tyosh...@google.com
mailto:tyosh...@google.com wrote:
On Wed, Oct 23, 2013 at 11:42 PM, Aymeric Vitte
vitteayme
(xhr,ws,etc), like for the structured clone algo, and this is missing.
Regards
Aymeric
Le 03/11/2013 19:02, Arthur Barstow a écrit :
Hi Aymeric,
On 10/29/13 7:22 AM, ext Aymeric Vitte wrote:
Who is coordinating each group that should get involved?
I thought you agreed to do
The main difference is that you are explaining in details what you are
doing and the current draft does not, I will look more closely and
comment, I am not sure the ES style really helps everybody understanding it.
Regards,
Aymeric
Le 04/11/2013 09:52, Domenic Denicola a écrit :
From:
I have seen the different bugs too, some comments:
- maybe I have missed some explaination or some obvious thing but I
don't understand very well right now the difference/use between
readable/writablebytestream and bytestream
- pause/unpause: as far as I understand the whatwg spec does not
this, it has been requested many times in node.
pipe/fork: I think b is better.
Regards
Aymeric
Le 06/11/2013 20:15, Takeshi Yoshino a écrit :
On Wed, Nov 6, 2013 at 7:33 PM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
I have seen the different bugs too, some
Le 07/11/2013 10:21, Takeshi Yoshino a écrit :
On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
stop/resume:
Indeed as I mentioned this is related to WebCrypto Issue22 but I
don't think this is a unique case. Issue22
Le 07/11/2013 10:42, Takeshi Yoshino a écrit :
On Thu, Nov 7, 2013 at 6:27 PM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
Le 07/11/2013 10:21, Takeshi Yoshino a écrit :
On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte
vitteayme...@gmail.com
Please see here https://github.com/whatwg/streams/issues/33, I realized
that this would apply to operations like textDecoder too without the
need of an explicit stream option, so that's no more WebCrypto only related.
Regards
Aymeric
Le 07/11/2013 11:25, Aymeric Vitte a écrit :
Le 07/11
I would expect Poc (stop, keep 0xd1 for the next data) and сия
It can be seen a bit different indeed, while with crypto you expect the
finalization of the operation since the begining (but only by computing
the latest bytes), here you can not expect the string since the begining
of course.
for any operation that has
unresolved bytes (TextDecoder, etc) without the need of modifying the
operation API for explicit clones or options.
Regards
Aymeric
Le 08/11/2013 14:31, Takeshi Yoshino a e'crit :
On Fri, Nov 8, 2013 at 8:54 PM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme
No, see my previous reply, unless I am proven incorrect, I still think
we should have:
- pause/unpause
- stop/(implicit resume)
Regards,
Aymeric
Le 11/11/2013 22:06, Takeshi Yoshino a écrit :
Aymeric,
Re: pause()/resume(),
I've moved flow control functionality for non-exact read() method
This is related to [1] (Use case) and [2] (Reduced test case)
This is about retrieving a large file with partial data and storing it
in an incremental way in indexedDB.
Instead of maintaining an incremented Blob, the real use case is
retrieving the Blob from indexedDB, doing new Blob([Blob,
://code.google.com/p/chromium/issues/detail?id=108012
Le 02/12/2013 23:38, Joshua Bell a écrit :
On Mon, Dec 2, 2013 at 9:26 AM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
This is about retrieving a large file with partial data and
storing it in an incremental
Aymeric
Le 03/12/2013 22:12, Jonas Sicking a écrit :
On Tue, Dec 3, 2013 at 11:55 AM, Joshua Bell jsb...@google.com wrote:
On Tue, Dec 3, 2013 at 4:07 AM, Aymeric Vitte vitteayme...@gmail.com
wrote:
I am aware of [1], and really waiting for this to be available.
So you are suggesting something
I am not especially connnected to MediaStream/ WebRTC, so probably it's
more efficient if Rob/Arthur do it.
I forward it to WebCrypto.
Right now there is still a list of bugs but regarding the current
edition I would comment what I already said separately to Takeshi/Feras:
I am not very
Le 07/02/2014 10:52, Anne van Kesteren a écrit :
As for createObjectURL(), it has not been a great success for Blob
objects. I'm not really sure we should widen that experiment. At least
not until the way they are supposed to be implemented for Blob objects
has actually been done in practice.
I don't see it on the wiki, so resuggesting storing blobs with partial
blobs, as discussed here
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0657.html
Regards
Aymeric
Le 16/04/2014 20:49, Joshua Bell a écrit :
At the April 2014 WebApps WG F2F [1] there was general agreement
Why IE(11) does not allow this while this is working on FF and Chrome?
[1] seems to suggest that it is by design.
Regards
Aymeric
[1]
https://connect.microsoft.com/IE/feedback/details/779379/unable-to-spawn-worker-from-blob-url
--
Peersm : http://www.peersm.com
node-Tor :
that it works in IE as well. Stay tuned. I updated the
Connect bug below.
-Original Message-
From: Aymeric Vitte [mailto:vitteayme...@gmail.com]
Sent: Friday, June 6, 2014 6:25 AM
To: Web Applications Working Group WG (public-webapps@w3.org)
Cc: Travis Leithead
Subject: IE - Security error
this is a problem and hope to be able to improve the situation soon.
-Original Message-
From: Aymeric Vitte [mailto:vitteayme...@gmail.com]
Sent: Tuesday, June 10, 2014 3:00 AM
To: Travis Leithead; Web Applications Working Group WG (public-webapps@w3.org)
Subject: Re: IE - Security error
Le 10/07/2014 19:05, Arun Ranganathan a écrit :
We agreed some time ago to not have partial data.
I still think that's a big mistake. Even if the Streams API will solve
this, this should be corrected in the File API.
Unless I am misusing the API, you can not even increment a Blob, you
you mention)
Regards
Aymeric
Le 17/07/2014 15:10, Arun Ranganathan a écrit :
Aymeric,
On Jul 16, 2014, at 8:20 AM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
Example:
var myfile=new Blob();
//chunks are coming in
myfile=new Blob([myfile,chunk],...)
//mylink
Back in this thread lately too...
I still don't see how you intend to solve the use case I gave:
- load 'something' progressively, get chunks (should be possible via xhr
but it's not)
- handle it via File augmenting the related Blob (not possible) and
store it progressively in indexedDB (not
/08/2014 11:46, Anne van Kesteren a écrit :
On Sun, Aug 24, 2014 at 11:59 PM, Aymeric Vitte vitteayme...@gmail.com wrote:
File, XHR and indexedDB should handle partial data, I thought I understood
from messages last year that it was clearly identified as a mistake.
This will be solved with streams
://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx
-Original Message-
From: Travis Leithead
Sent: Tuesday, June 10, 2014 5:54 PM
To: Aymeric Vitte; Web Applications Working Group WG (public-webapps@w3.org)
Cc: Adrian Bateman
Subject: RE: IE - Security error
about low/high level and Vx releases, eluding the issue.
Le 01/09/2014 11:14, Anne van Kesteren a écrit :
On Thu, Aug 28, 2014 at 2:15 AM, Aymeric Vitte vitteayme...@gmail.com wrote:
I have contributed to streams already, of course it will solve most of what
is being discussed here but when
yes for me, use cases are legion)
but to make it work on the field with streams and finalize the spec
accordingly, same thing for the other APIs.
Regards,
Aymeric
Le 04/09/2014 02:39, Arun Ranganathan a écrit :
On Sep 3, 2014, at 6:02 PM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme
, Takeshi Yoshino a écrit :
On Thu, Sep 11, 2014 at 8:47 AM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
Does your experimentation pipe the XHR stream to MSE? Obviously
that should be the target for yt, this would be a first real
application
, Aymeric Vitte wrote:
As directed in [1], if anyone wants to reply to this thread, please use
the public-patent-issues list and do *not* reply on public-webapps.
-Thank you, AB
[1]
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0912.html
--
Check the 10 M passwords list: http
, scope
and applications
http://www.peersm.com/gist3.html: Polymer vs Extract Widget patent -
Code comparison
http://www.peersm.com/gist4.html: Components model comparison with the
patent
Le 16/06/2015 01:27, Aymeric Vitte a écrit :
We have made a comparison between the Components model
We have made a comparison between the Components model and the patent
here: https://gist.github.com/Ayms/bf6a9f121e1ebd93cf22
From the end-2011 Components Model we have added some
properties/thoughts/proposals from the patent and our past projects.
Each time we read something about the
obvious too that if we can import and construct a
shadow domed web component, we can extract it the same way, that's the
same thing.
Regards,
Aymeric
Le 22/05/2015 00:01, Aymeric Vitte a écrit :
Since this is public now for everybody, please let me give some
additional information.
We think
Since this is public now for everybody, please let me give some
additional information.
We think that the extraction mechanisms described in the patent and not
covered by any spec will happen one day too, and could be integrated in
the Web Components spec, the purpose being to extract a
Whatever we call it the "protocol worker" exchanges data between two
apps, and as I suggested the data can be a Web Component itself, part of
it, what is needed by the receiving app, the result can be anything too,
it can be passed back to the calling app, be HTML code, be a customized
Web
I don't see any technical difficulty to spec and implement this (except
maybe how to avoid the horrible pop-up effect) and this covers everything."
Le 18/10/2015 20:49, Chaals McCathie Nevile a écrit :
> On Sun, 18 Oct 2015 19:09:42 +0200, Aymeric Vitte
> <vitteayme...@gmail.com>
Ccing the authors of [1], [2] and [3] if there is still an interest.
>
> at this stage we don't have a deliverable for this work - i.e. the W3C
> members haven't approved doing something like this in Web Platform working
> group. Given that people repeatedly attempt to do it, I think the
>
Le 17/10/2015 17:58, Chaals McCathie Nevile a écrit :
> Aymeric, that could apply to you to - and in fact the requirement to
> behave courteously is a general one for this list and others of the Web
> Platform WG
Replying only to this for now, you don't know what you are talking about
and don't
Le 17/10/2015 16:19, Anders Rundgren a écrit :
> Unless you work for a browser vendor or is generally "recognized" for some
> specialty, nothing seems to be of enough interest to even get briefly
> evaluated.
>
Right, that's a deficiency of the W3C/WHATWG/whatever specs process,
where people
uncation of a SHA-1 hash of
> a 1024 bit key, I don't think you'll get much traction in insisting it
> is equivalent to or better than TLS.
>
> On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte <vitteayme...@gmail.com
> <mailto:vitteayme...@gmail.com>> wrote:
>
> R
ox" is solved), I am not talking about this for now,
I am talking about using the Tor protocol or another secure protocole
for multiple services.
>
> -Brad
>
> On Tue, Dec 1, 2015 at 5:42 AM Aymeric Vitte <vitteayme...@gmail.com
> <mailto:vitteayme...@gmail.com>> w
Le 02/12/2015 13:18, Florian Bösch a écrit :
> On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte <vitteayme...@gmail.com
> <mailto:vitteayme...@gmail.com>> wrote:
>
> Then you should follow your rules and apply this policy to WebRTC, ie
> allow WebRTC to work o
sandboxed context with
service workers.
Le 25/11/2015 17:43, Aymeric Vitte a écrit :
>
>
> Le 20/11/2015 12:35, Richard Barnes a écrit :
>> On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck <ha...@hboeck.de> wrote:
>>
>>>> It's amazing how the same wrong argumen
dy the case.
Let's stop talking about Tor, please just explain why ws cannot be used
with https.
Le 01/12/2015 00:08, Richard Barnes a écrit :
> On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte <vitteayme...@gmail.com
> <mailto:vitteayme...@gmail.com>> wrote:
>
> You m
bout WebRTC and DTLS self-signed certificates that the web is
trying to secure by some strange ways?
Le 30/11/2015 22:45, Richard Barnes a écrit :
>
>
> On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte <vitteayme...@gmail.com
> <mailto:vitteayme...@gmail.com>> wrote:
>
&g
Le 01/12/2015 05:31, Brad Hill a écrit :
> Let's keep this discussion civil, please.
Maybe some wording was a little tough below, apologies for this, the
logjam attack is difficult to swallow, how something that is supposed to
protect forward secrecy can do quietly the very contrary without
70 matches
Mail list logo
