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.
Putting on PDT- radar. Porkjockey work.
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.
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.
Summary: [DOGFOOD] implement AsyncOpen for file and resource protocol → implement AsyncOpen for file and resource protocol
We determined that we don't need AsyncOpen anymore. Won't fix.
Won't fix. (really this time)
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WONTFIX
development issues - closing
Status: RESOLVED → CLOSED
You need to log in before you can comment on or make changes to this bug.