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
_______________________________________________
dev-embedding mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-embedding
