Closed
Bug 18414
Opened 25 years ago
Closed 25 years ago
implement AsyncOpen for file and resource protocol
Categories
(Core :: Networking, defect, P3)
Tracking
()
CLOSED
WONTFIX
M15
People
(Reporter: warrensomebody, Assigned: warrensomebody)
References
Details
(Whiteboard: [PDT-])
In today's pork jockey meeting we determined that we must implement AsyncOpen
for all of our protocols in order to implement URL dispatching. This allows to
determine the content type of the incoming stream before determining the
recipient of the stream.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12 → M13
Assignee | ||
Comment 2•25 years ago
|
||
We might be off the hook for this if I can convince mscott (and myself) that we
don't need it, and that a delegating stream listener would do the trick. Moving
to m13.
Bulk move of all Necko (to be deleted component) bugs to new Networking
component.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M13 → M15
Assignee | ||
Comment 4•25 years ago
|
||
Moving to M15. I'm still hoping that AsyncOpen can go away altogether, but
apparently there's the problem of knowing the content type before deciding
whether to do a synchronous or asynchronous read. That seems suspicious to me.
Updated•25 years ago
|
Summary: [DOGFOOD] implement AsyncOpen for file and resource protocol → implement AsyncOpen for file and resource protocol
Assignee | ||
Comment 6•25 years ago
|
||
We determined that we don't need AsyncOpen anymore. Won't fix.
Assignee | ||
Comment 7•25 years ago
|
||
Won't fix. (really this time)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•