Closed Bug 18416 Opened 25 years ago Closed 25 years ago

implement AsyncOpen for jar protocol

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
All
Other
Type:
defect

Tracking

()

Status:
CLOSED WONTFIX

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.
Depends on: 14928
No longer depends on: 14928
Blocks: 14928
Target Milestone: M12
Whiteboard: [PDT-]
Putting on PDT- radar.  Porkjockey work.
Target Milestone: M12 → M13
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.
Target Milestone: M13 → M15
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.
Putting dogfood in the keyword field.
Keywords: dogfood
Summary: [DOGFOOD] implement AsyncOpen for jar protocol → implement AsyncOpen for jar protocol
We determined that we don't need AsyncOpen anymore. Won't fix.
Won't fix. (really this time)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
development related - closing
Status: RESOLVED → CLOSED
You need to log in before you can comment on or make changes to this bug.