Confirmed users
431
edits
| Line 71: | Line 71: | ||
bz suggests that we can accomplish this without having the content process read the file by creating a new kind of stream class, in which the content process marks the name of the file and the chrome process actually reads it from disk and uploads it. | bz suggests that we can accomplish this without having the content process read the file by creating a new kind of stream class, in which the content process marks the name of the file and the chrome process actually reads it from disk and uploads it. | ||
==== Channel "owner" ==== | |||
Channels have Set/GetOwner methods, used to store the principal responsible for the request. | |||
* Apparently not used much for HTTP? | |||
** jst: CSP (Content Security Protocol) may use? | |||
* Not clear if get & set only on content side, or if set only on content, but read by both chrome/content. Find out and propagate as needed | |||
* bz would like to rework this API anyway | |||
=== FTP === | |||
* Doug Turner knows this code. | |||
* Proposal from bsmedberg: we keep FTP purely within the chrome process, so that we don't need to make it IPC-savvy. | |||
** We would only allow files to be downloaded (not rendered within browser) via FTP. | |||
** browsing of FTP server tree would be done by hiding content process tab with a chrome one when a FTP directory is the target. | |||
** FTP also supports upload--used by seamonkey and composer--but this happens all in chrome, so no changes needed? | |||
= Carving work into subprojects = | = Carving work into subprojects = | ||