Darin Fisher <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Jacek Prucia wrote: [...] > > but > >it is possible for the same URL to appear multiple times across single > >document (multiple blank.gif images or so), so this won't do. > > > > > > actually, the image cache makes it so that you hardly ever see this happen.
Yes, but I would like to avoid that. If page has 2 identical pictures, then I want onModifyRequest/onExamineResponse calls for every of them, regardles of their source (network, local cache). Is there any way to have such behaviour without something stupid like: nsIRequest.loadFlags having INHIBIT_PERSISTENT_CACHING? > but, the possibility still exists... especially with things other than > images. Yes. > maybe you can use the address of the nsIChannel object? in JS i think > you can compare the native address of two JS objects by using the '===' > operator. Looks like you're right. However, JS 1.5 spec says, that '===' (so called 'strict equals') just checks types. Nothing about addresses of objects, so I'm not sure if I can relay on this... The only nitpick here is that I can't use JS arrays like this: myHash = new Array(); myHash[someIndex] = HttpChannel; ...because that simply doesn't work. However using nsIArray and nsIMutableArray to store HttpChannel gives great results, so '===' operator is ok. > though, there could be issues with such an approach. > assuming you build a table mapping some key (generated from the > nsIChannel) to your associated data, you still have the problem that you > don't know when you can remove an element from the table. for example, > you might get an onModifyRequest event for a channel, but there is no > guarantee that you will see an onExamineResponse. this is because > onExamineResponse is only called when a transaction succeeds. > > you might have better luck implementing nsIWebProgressListener. (you > should get a ton of hits in LXR if you search for nsIWebProgressListener.) Yep, just tell me one thing: what state indicates transfer failure? Looks like there is no dedicated 'connection died' state, so I guess there's other condition (probably premature STATE_STOP) that means transfer failure, right? > nsIWebProgressListener still doesn't help with the "associating some > context with a nsIChannel" though :-/ Yes and I'm affraid, that this '===' operator trick might be fragile. It would be more bullet-proof if some scriptable XPCOM interface, or at least XPConnect wrapper object would expose method, that would return XPCOM object address as a plain string. That would be unique enough for me. regards, -- Jacek Prucia _______________________________________________ Mozilla-netlib mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-netlib
