If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[RFE] need to expose a generic stream load api.

VERIFIED FIXED

Status

()

Core
Document Navigation
P3
enhancement
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Judson Valeski, Assigned: Judson Valeski)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

Attachments

(1 attachment)

(Assignee)

Description

18 years ago
There are instances in which the embedding app may want to supply it's own data
(BYOD). There may or may not be a URI involved. Imagine an embedding app that
simply has a buffer of html data it wants to load. They should just have to wrap
that buffer in an nsIInputStream and hand it off ot the uri loader (note: we
need to expose this api to the high level embedding api as well). Actually,
maybe we should supply a Load(char *buffer) method as well so they don't even
need an inputstream???

Comment 1

18 years ago
How about letting the client register with a special protocol handler that calls 
back to a client supplied object with a simple interface whenever content is 
requested? The client wouldn't need to write the protocol handler, just the 
callback. The callback would contain a single, simple method - "give me back a 
chunk of memory representing this URI". The protocol handler then takes the 
memory stuffs it in a stream and sends it off before deleting it.
(Assignee)

Comment 2

18 years ago
I've seen a current implementation do this. Part of the problem is that
initiation of the special handler isn't always clear (you basically have to
generate a "foo:" url to kick things off).

Usually the client knows when it wants to initiate the rendering, and it
supplies its own buffer. Exposing a more raw Load() method has the same affect,
yet all the client has to do is supply the buffer, and we don't have to involve
a protocol handler.

I think we sould try to avoid "special case" scenarios as they cloud
architecture lines.
(Assignee)

Comment 3

18 years ago
nom nsbeta2. fix attatched. mscott and rpotts have both reviewed it. This change 
extends the nsIDocShell api such that it can load data from a stream rather than 
an api. embedding clients need this so they can bypass our networking level to 
render data.
Assignee: rpotts → valeski
Keywords: nsbeta2
(Assignee)

Comment 4

18 years ago
Created attachment 10583 [details] [diff] [review]
fix

Comment 5

18 years ago
valeski, feel free to mark [nsbeta2+] when you are comfortable to go ahead on 
this.
Whiteboard: [Jud To Do]
(Assignee)

Updated

18 years ago
Whiteboard: [Jud To Do] → [nsbeta2+]
(Assignee)

Comment 6

18 years ago
fixed. this method now hangs off of the docshell.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 7

17 years ago
Adding verifyme keyword.
Keywords: verifyme

Comment 8

17 years ago
Per valeski, ok to mark this Verified.  Fixed is good!  Goal!
Status: RESOLVED → VERIFIED

Comment 9

15 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement

Updated

9 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.