IRC Log Viewer » #firebreath » 2011-10-08

IRC Nick Time (GMT-7) Message
linearray 11:10 taxilian: do you find your macbook pro sufficient for all your work by now?
or do you expect it to be once the SSD works? :)
taxilian 11:10 linearray: it has been for quite awhile, though I often use a second windows laptop for convenience
it'll be much better when the SSD works, though =]
linearray 11:10 I've been using a mbp for the longest time, but switched to an imac for performance reasons
but the lack of mobility bothers me by now
taxilian 11:10 linearray: I actualy have both
I have a 27" imac in my office, and a 17" macbook pro for mobility
but the macbook pro outperforms the imac, since it's a year (maybe two, actualy) newer
linearray 11:10 interesting
taxilian 11:10 I'm guessing with the 512MB SSD it'll probably fly
but I'll still use the imac at home most of the time because it's set up nicely, can run all the time, and has more screen realestate
linearray 11:10 do you have a 2011 macbook pro or 2010?
taxilian 11:10 2011
I had a 2009, sold it this year and bought the 2011
linearray 11:10 I guess I'll just buy a SSD and postpone buying a new computer
taxilian 11:10 hehe. well, I'll let you know how noticable the difference is when I get it next week
linearray 11:10 until next summer, when I can't stand the glossy screen
and the heat in here that makes me want to flee the scene
taxilian 11:10 I had a 2010 laptop w/ a 256GB SSD from Facebook when I was working for them, and it really wasn't any faster
but this drive is much much faster than that one
hehe. have you thought about getting an anti-glare screen protector?
something like this? http://www.powersupportusa.com/accessories/macbook-pro-17/anti-glare-film.html
I have one for my ipad and iphone, and they work really well; I bet it'd be nearly as good as having the matte display
linearray 11:10 interesting... I shall try one on the imac
taxilian 11:10 dunno if they have them for an imac
linearray 11:10 I'm a sucker for apple displays, even though I can't stand them, because of working brightness controls, isight and USB
taxilian 11:10 that's a good point
lol
linearray 11:10 I don't get it why other manufacturers don't have drivers for working brightness control
taxilian 11:10 heh
linearray 11:10 I have read before that the problem is there's a glossy panel beneath a glass screen on the imac
so you actually have two sources of glare
that's why an anti-glare film does not work well
but I might just try it
Mort 16:10 Hi all o/
Sorry to bother you guys; I had a quick question related to FireBreath, and I'm not sure if this is the best place for it.
linearray 16:10 this is an excellent place to ask questions related to FireBreath
Mort 16:10 Ah, perfect. I saw a room full of people and wasn't sure if I'd been redirected or joined the wrong channel ;D
linearray 16:10 in fact the place is so good for that, it's even called #firebreath
:)
Mort 16:10 Basically, I was trying to figure out if there was a way to either A) cancel a BrowserStream download in progress, or B) issue a HEAD request to the server (rather than a full blown GET) to get the headers early via the existing FireBreath API
I tried calling BrowserStream::close() to cancel the download, but it resulted in some strange behaviors (triggering 'onStreamCompleted()' twice, once with success (first) and then failure (second)) so I'm not sure if this is even a valid approach :)
If it makes a difference, I'm using a pretty simple subclass of DefaultBrowserStreamHandler() with a stream created via BrowserHost::CreateStream(). The call to 'BrowserStream::close()' was made in response to the 'onStreamOpened()' event (after analyzing the headers).
linearray 16:10 !wiki httpcallback
FireBreathBot 16:10 0 results found. Note: Results limited to 8
linearray 16:10 unfortunately I have no idea
Mort 16:10 Ok, not to worry. I'll do some more digging and perhaps put something together to grab the headers directly without initiating a full download. I mainly wanted to double check that this feature was not already available. Many thanks for your assistance anyway, I appreciate your time.
taxilian 16:10 sorry, just got back; whats the question?
hmm. I see the question now
Mort 16:10 Oh, hi taxilian
taxilian 16:10 I'm trying to find out for sure, but I'm not certain that NPAPI even supports canceling a request
pretty sure it doesn't, in fact
hmm. actually, maybe it does
calling NPN_DestroyStream seems like it should do it
likely there is just something in the BrowserStreams code that doesn't take that possibliity into account
you could probably fix it
Mort 16:10 ok, that's perfect. I can do some debugging and follow that process through to see where things go awry
taxilian 16:10 good luck; keep in mind that there are two different implementations you need to deal with
Mort 16:10 I figured the largest problem was my choice of location for the 'close()' call (inside the 'opened' event, which I was certain was bound to cause problems ;))
taxilian 16:10 the first is the NPAPI one, and the second the ActiveX one
ActiveX is used only on IE
that is quite possible
I don't know, since I didn't write that code
Mort 16:10 In relation to the second option, do you know if it's even a possibility to issue a 'HEAD' request via the NPAPI (I'm not at all familiar with it)?
taxilian 16:10 not as far as I know
though it might be possible if it's a seekable stream
Mort 16:10 I don't believe so, unfortunately. I can call out to the server directly, but it would be ideal if I could honor the browser's proxy settings. Ok, not to worry. I'll definitely move forwards with investigating the stream destruction. If I find any problems / make improvements in this regard, should I submit a patch?
(I mean, I don't believe I can guarantee it's seekable)
taxilian 16:10 absolutely
we like patches =]
git format-patch or pull requests are easiest
Mort 16:10 ;D Ok, got it.
taxilian 16:10 incidently, you can get the browser's proxy settings if you're on a recent version of NPAPI
there is an API to get it
older versions will fall back to the IE browser
but of course we can't get the authentication info, if any
Mort 16:10 Ah, yes. I think I remember reading that this required Firefox 3.6+ (actually, I think it was one of your answers on Stackoverflow)
taxilian 16:10 sounds familiar
=]
linearray 16:10 what are reasons for utilizing the browser instead of doing your own socket programming?
Mort 16:10 Handling the proxy details seems like a giant pain in the rear overall.
taxilian 16:10 generally the reason is to support proxies properly
Mort 16:10 (for this kind of work I mean)
taxilian 16:10 oh, it is
a huge pain
Mort 16:10 A secondary bonus for me is that I have little to no experience with socket programming on non-windows platforms, so it sort of kills two birds with one stone (at least that's the plan ;))
Anyway, thanks to you both for the assistance. I'll head back and see what the deal is with this destruction process to see if I can refine it a little for my purposes.
taxilian 16:10 good luck
linearray 16:10 if you want to do socket programming with firebreath, use boost::asio, it takes care of platform-independence