Necko: Difference between revisions

19 bytes added ,  11 January 2006
m
Line 14: Line 14:
** Yes, we could do it that way.  However, there are issues to figure out such as whether or not blocking on a synchronous stream should block the UI from processing events.
** Yes, we could do it that way.  However, there are issues to figure out such as whether or not blocking on a synchronous stream should block the UI from processing events.


* Support unicode file paths.  This impacts the way we encode file URLs.  Currently, we encode them in the "native filesystem charset" and then %-escape any non-ASCII bytes.  This is not going to work if we wish to support full unicode file paths because the conversion from unicode to "native filesystem charset" may be lossy.  See {{bug|162361}}.
* Support unicode file paths.  This impacts the way we encode file URLs.  Currently, we encode them in the "native filesystem charset" and then %-escape any non-ASCII bytes.  This is not going to work if we wish to support full unicode file paths because the conversion from unicode to "native filesystem charset" may be lossy.  See {{bug|162361}} and {{bug|278161}}.


* Optimize nsIURI construction (nsStandardURL::SetSpec).  We may be able to shave off some cycles here by ensuring that the input string is assigned directly to mSpec when it is determined that no canonicalization is required.  This will in many cases allow us to simply share the given string buffer instead of having to copy it.
* Optimize nsIURI construction (nsStandardURL::SetSpec).  We may be able to shave off some cycles here by ensuring that the input string is assigned directly to mSpec when it is determined that no canonicalization is required.  This will in many cases allow us to simply share the given string buffer instead of having to copy it.
3

edits