On Feb 18, 12:24 pm, Boris Zbarsky <[email protected]> wrote: > Seong-June Kim wrote: > > 1) It works well for html files and images, but it can't handle flash > > files (.swf) and javascripts (.js), etc., which the "http" and "file" > > protocols > > handle flawlessly. > > Can't handle in what sense? Do they just not load or something? > > Is there a reason you're not setting a MIME type on the channel? I can > certainly see that causing issues with content dispatch (e.g. flash), > though not with linked scripts. > > > 2) The pipe (nsIPipe) seem to break when I write more than 64k bytes > > into it. > > You're creating a pipe with a non-blocking input, non-blocking output, > default segment size (4KB) and default segment count (16). You never > read from the pipe, but you write data to it. > > So after writing 64KB the pipe is full, and the writeByteArray() method > in your case will throw NS_BASE_STREAM_WOULD_BLOCK. This is documented > behavior for the write() method of a non-blocking output stream; see > nsIOutputStream.idl. > > If you meant to create an infinite-sized pipe, you should pass the > appropriate arguments to init(). See nsIPipe.idl. > > > While writing to it in a separate thread pausing from time to time > > seem to work > > Presumably because the input end of the pipe was being read from in > between your writes, right? > > > what would you recommend as a more desirable and elegant way? > > Either use the separate thread and pause the writing when you get > NS_BASE_STREAM_WOULD_BLOCK or use an infinite pipe. The choice depends > on your general implementation details. The infinite pipe approach is > probably preferable for things like getting content-length right, fwiw. > > -Boris
Initializing the pipe with infinite space did the trick. I should've read the doc carefully. Thanks a lot! -Seong _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
