Bug 1452600 Comment 42 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

OK... my (still somewhat shaky) take on the various approaches, using the suggestions in bug 1520868 comment #7:

3. seems worth pursuing, but relies on the `request` param of the `On[Start|Stop|Data]Request` callbacks being QI-able to `nsIChannel`, so we can get at the URI. Presumably we can do this easily enough for all the TB-specific protocols - there don't seem to be too many to go through. But assumes that URI is the only thing we're passing via `ctxt`.

2. could be handy, but seems wrong to force a listener to be coupled to a specific request like that. But maybe they're already pretty closely coupled.

1. is problematic because while you likely know what the concrete type of the channel is when you call `AsyncOpen()`, the listener _doesn't_ know the concrete type - it just sees a `nsIRequest`. If the listeners can assume particular types of channels, then they can QI back to a concrete type and ask it for the extra context, but that seems a little iffy.
I think the `nsIURIHolder` approach falls into this category.
OK... my (still somewhat shaky) take on the various approaches, using the suggestions in bug 1520868 comment #7:

3) seems worth pursuing, but relies on the `request` param of the `On[Start|Stop|Data]Request` callbacks being QI-able to `nsIChannel`, so we can get at the URI. Presumably we can do this easily enough for all the TB-specific protocols - there don't seem to be too many to go through. But assumes that URI is the only thing we're passing via `ctxt`.

2) could be handy, but seems wrong to force a listener to be coupled to a specific request like that. But maybe they're already pretty closely coupled.

1) is problematic because while you likely know what the concrete type of the channel is when you call `AsyncOpen()`, the listener _doesn't_ know the concrete type - it just sees a `nsIRequest`. If the listeners can assume particular types of channels, then they can QI back to a concrete type and ask it for the extra context, but that seems a little iffy.
I think the `nsIURIHolder` approach falls into this category.
OK... my (still somewhat shaky) take on the various approaches, using the suggestions in bug 1520868 comment #7:

3 seems worth pursuing, but relies on the `request` param of the `On[Start|Stop|Data]Request` callbacks being QI-able to `nsIChannel`, so we can get at the URI. Presumably we can do this easily enough for all the TB-specific protocols - there don't seem to be too many to go through. But assumes that URI is the only thing we're passing via `ctxt`.

2 could be handy, but seems wrong to force a listener to be coupled to a specific request like that. But maybe they're already pretty closely coupled.

1 is problematic because while you likely know what the concrete type of the channel is when you call `AsyncOpen()`, the listener _doesn't_ know the concrete type - it just sees a `nsIRequest`. If the listeners can assume particular types of channels, then they can QI back to a concrete type and ask it for the extra context, but that seems a little iffy.
I think the `nsIURIHolder` approach falls into this category.

Back to Bug 1452600 Comment 42