IRC Log Viewer » #firebreath » 2010-11-11

IRC Nick Time (GMT-7) Message
DFUN 06:11 Here's one more question about the BrowserStream...
it looks as though the "StreamCompleted" event isn't sent. At least my BrowserStream-subclass doesn't receive any event other then "StreamCreated", "StreamOpened" and "DataArrived"
the base class is FB::DefaultBrowserStreamHandler
all methods are registered like EVENTTYPE_CASE(FB::StreamCompletedEvent, onStreamCompleted, FB::BrowserStream)
I'm using the FB 1.3.0 release
the method is defined as bool onStreamCompleted (FB::StreamCompletedEvent *evt, FB::BrowserStream *Stream);
i.e. it overwrites the base class
iaincollins 07:11 It's been a decade since I wrote anything significant in C++ (since then just a few web, ldap and ftp server modules and small hacks to PHP since then),
I am super-happy at discovering boost through using FB
DFUN 08:11 similiar to me. I just wrote a lot of C# the last month and now C++ takes a long warm-up again
iaincollins 08:11 yeah, I write a fair bit of C# too (some app, some webservices, .NET+Mono), I actually thought I'd miss it more :)
Mono is great on Unix, but building on Windows can be a pain, and there is a bit of work to do on the Mac GUI integration side (though it's usable, it's not pain free yet)
DFUN 08:11 c# is fast to wrtie and quite easy to learn. Additionally it's much better supported by Visual Studio.
since now I wrote for Windows platforms exclusively
iaincollins 08:11 Yeah VS with C# is awesome as a development environment
and I come from an Mac OS (classic+) and Unix background, never thought I'd be saying that :/
DFUN 08:11 :D
iaincollins 08:11 I was at a Microsoft Dev meeting in Reading a while ago, mostly Delphi developers transitioning to .NET (to varying degrees)
DFUN 08:11 why not... auto completion, great debugging, it all works fine.
iaincollins 08:11 MacBooks + VMWare/Parallels + VS was definately very popular amoung the attendees :)
DFUN 08:11 but the results are definitely slower than C code
iaincollins 08:11 yeah, although probably fine for most business apps that people need to churn out
DFUN 08:11 which attendees do you mean?
iaincollins 08:11 I'm starting to have bad thoughts about how neat it would be to write NPAPI plugins with Firebreath and then distribute apps (via something like Prisim) with them embedded
DFUN 08:11 hmm... yea, let me think about it.
iaincollins 08:11 oh just developers giving talks, Microsoft holding the meetings in their UK HQ, and a rep gives talks sometimes, various developers and solution providers (such as vendors of debugging tools) come and show off their solutions
they did a comparison of cross platform development kits and approaches, which was neat
(at one of the most recent ones I went to)
DFUN 08:11 should be about time to get some robust frameworks for cross platform development. Or at least one. But that's nothing Mircosoft would push, wouldn't they?
but I'm really new to this discussion and lucky to have a plugin framework
iaincollins 08:11 yeah, I underestimated the amount of work required for an NPAPI browser plug-in bigtime, also feel very lucky to have FB
or, more precisely, I underestimated how much work it would be to do both an ActiveX and NPAPI plug-in at the same time
I am sure I would have had to do them as seperate projects (and increased the work required significantly)
DFUN 08:11 I'm lucky to never have got in touch with those questions
but now I'm stucked with the assumed bug at the browser stream... unfortunately taxilian cannot be aroung all day
taxilian 08:11 lol. so DFUN left, huh? and 25 minutes before I got here :-P
always seems to happen that way
DFUN 09:11 poor you, taxilian. Now it's seem lucky for both of us I'm back again :)
I'm about to leave, actually,... but I'm interested if you know something about my problem
taxilian 09:11 lol
DFUN: neil is probably the best here to ask about that, actually;
neil, you around?
I promise that looking over the BrowserStreams stuff is on my list =]
DFUN 09:11 since I'm going to have a long weekend I don't want to undergo it unknowing
ok, that would be nice. I hope it's not my mistake. But I'm pretty sure that I use the class correctly
I can follow the download in the debugger and the breakpoints in the Completed-method are never reached, so...
did you notice my first contribution to the wiki?
hope it's not erroneous - since my stream handler doesn't work :)
but as a first draft for other people like me it should do his job
amackera 09:11 DFUN: linkage?
ie what's the url :P
DFUN 09:11 http://firebreath.googlecode.com/files/firebreath-stable-1.3-nightly72.7z
or that one http://www.football-pictures.net/data/media/279/Weserstadion_HD_Pictures.jpg
taxilian 09:11 DFUN: just looked at it; looks good
http://www.firebreath.org/display/documentation/Handling+downloads+using+FireBreath
DFUN 09:11 nice, thank you
maybe the link can be replaced from "Digging Deeper"
you know better where it belongs to
taxilian 09:11 I moved it into the tree heirarchy
DFUN: I sent nitro an IM asking if he has any ideas; dunno if he's around or not, though
DFUN 09:11 ok
no hurry for me. I'll be away till tuesday
taxilian 09:11 DFUN: which browser?
DFUN 09:11 I'll get in contact with you then.... or I'm gonna check to logs
Firefox
3.6.11
taxilian 09:11 ok; you could dig down into the BrowserStream class itself and see if you can track it down
I'm suspecting neil may know the answer, though :-/ just doesn't seem to be around
neil 09:11 *poof* Did somebody call? lol
taxilian 09:11 hey, it's neil!
amackera 09:11 lol
DFUN 09:11 there he is.... and makes me sit around at work a little longer
taxilian 09:11 fix DFUN's problem, could you? thanks
;-)
*poof*
does that help?
neil 09:11 lol
amackera 09:11 haha
DFUN 09:11 hope it magic, not farting
it's
amackera 09:11 haha, we can only hope
neil 09:11 I noticed the same thing, I can't remember whether I fixed it or not. I suspect not though since the status bar of the browser always says something like "Requesting data from <url>"
But let me check and see
DFUN 09:11 ok, neil, I assume a bug here since I defined, implemented and registered all events the same way. The DataArrived-event is called, the Completed-event isn't
right now I check for (progress == 100) to close the file in the DataArrived event.
taxilian 09:11 that seems logical; would you mind submitting an issue for this so we don't lose track of it?
DFUN 09:11 I'm not registered at Google code project yet, but let me see
neil 09:11 That's also exactly how I handle it too
taxilian 09:11 DFUN: any google account can be used
DFUN 09:11 at least it works
neil 09:11 Well, I don't rely on progress - I rely on receiving the amount of data the server tells me to receive
taxilian 09:11 it may be that BrowserStreams is waiting for a DestroyStream and the browser isn't calling it :-/
neil 09:11 But the theory is the same
DFUN 09:11 but I want to use the Completed-event to through another event to delete the stream handler
neil 09:11 Oh, I found the bug
DFUN 09:11 oh, great
neil 09:11 I really need to commit my fixes...
DFUN 09:11 :) what a great idea
taxilian 09:11 sounds good to me as well ;-)
1.4 is currently tentatively scheduled for early next month; it would be good to have this in sooner than later, though, so that we can get some good testing on it
neil 09:11 In the meanwhile I can tell you that the problem is in NpapiStream.cpp on line 61
It checks isSeekable() but shouldn't
I haven't tested this though, this is just an educated guess
taxilian 09:11 huh; that does seem strange
neil 09:11 Perhaps I should have said that first rather than sounding like I was certain. But it shouldn't be checking for that - I fixed another (similar) bug in the same way
taxilian 09:11 why would it matter if it is seekable?
neil 09:11 Exactly
taxilian 09:11 neil: if you want, you could just send me the "hg diff" for NpapiStream.cpp
DFUN 09:11 so the fix is just deleting isSeekable() in line 61?
taxilian 09:11 probably
neil 09:11 Yup
That's my theory
taxilian 09:11 test it for me and let me know =] if so, we'll make the change
DFUN 09:11 let me test it quickly
neil 09:11 I fixed another relevant bug with opening streams in exactly the same way
DFUN 09:11 ...gotta close my browser.
taxilian 09:11 hehe. I guess the web-based IRC client was worth taking the time to put on the page =]
DFUN 09:11 hmmm...
I'm sorry to tell but...
taxilian 09:11 can you try setting a breakpoint in close() and see if it gets hit?
DFUN 09:11 even the breakpoint in the first line of NpapiStream::close isn't reached
...
neil 09:11 Yeah, I spoke too soon
The fix is still in there
In NpapiStream::signalCompleted(bool success)
Line 110
It also checks isSeekable() and if so... never sends the event nor calls close()
DFUN 09:11 if ( isSeekable() && success ) return; line 108
that's the one
taxilian 09:11 right; any idea what he's talking about in the comment there?
neil 09:11 I'm a little out of date, I need to pull again
No, I don't understand that comment - that's not how streams work AFAIK
The server I normally download from sets my streams as seekable (which is how I found the bugs I did) and I never saw it closing the stream
DFUN 09:11 signalCompleted is called to times both with its parameter success = true
neil 09:11 Also: even if that were true I don't see the harm in being told the stream completed twice since you need to rely on when data arrives in any case
DFUN 09:11 so return is performed anyway
neil 09:11 I think he's trying to handle bad browser behaviour - I've seen Chrome (I think?) tell me streams have closed multiple times
But that's a bug in the browser
taxilian 09:11 hmm
neil 09:11 At least that's my take on what's going on - I could be completely wrong
taxilian 09:11 seems like the first time it is called should be when the event fires; if it is called again it should be ignored
neil 09:11 I know I had to handle that in my pre-FB plugin
DFUN 09:11 the callers are different
taxilian 09:11 as of yet I have never used streams in any way, so I don't know =]
though I will be using them soon
DFUN 09:11 NpapiPlugin::DestroyStream and NpapiPlugin::URLNotify
both with parameter (reason == NPRES_DONE) = true
neil 09:11 I think a good change would be changing "if ( isSeekable() && success )" to "if ( isSeekable() && success && completed)"
That shouldn't change any behavior and I believe solves what was trying to be handled there
DFUN 09:11 ok, let me try that
neil 09:11 Oh my god I'm turning American, that's the first time I've spelt "behavior" without a "u" without meaning to... :o
lol
taxilian 09:11 lol
DFUN_ 09:11 debug hanged
taxilian 09:11 hey, aye kin spell just fine, an Im american
iaincollins 09:11 *if
taxilian 09:11 no, it's not :-P
neil 09:11 I'll brb, it's lunchtime!
Hopefully that works - if not then I'll look into it deeper. It's been annoying me too. ;)
DFUN 09:11 :)
finally
you surely deserved your weekend more than I did... but now I'm going anyway
taxilian 09:11 well, I gotta run and get breakfast. I'll be back in 30-45 minutes. DFUN, since you'll probably be gone when I get back, I wish you luck and will talk to you next week
DFUN 09:11 thanks alot and see you next week.
right. Good day
and good evening
taxilian 10:11 neil: you back?
neil 11:11 Just got back
Actually, in case you have notifications... taxilian: just got back
taxilian 11:11 welcome back
so I talked to nitro a bit
he says that isSeekable() should never return true unless you request a seekable stream
and the reason that it doesn't fire completed if it's seekable is that you could do additional reads
neil: so maybe the bug is that it thinks it's seekable when it shouldn't be
neil 11:11 Yes, I fixed that locally. Damnit.
Damn me for not commiting it yet...
I believe I've fixed it for *me* but nobody else
taxilian 11:11 hehe
neil 11:11 What was happening is it sets the stream to streamable if the server supports it whether you requested it or not - which almost makes sense but not when the behaviour changes depending on whether the stream is seekable or not
I need to push my changes somehow - half the reason I haven't done that is my changes are to the side of my FB hg checkout... The other half being I don't know how to push my changes. ;)
taxilian 11:11 yeah, it should treat it as non-seekable unless you request a seekable stream
neil 11:11 Right; I can understand the thinking there but it doesn't make sense
taxilian 11:11 from what he said that's the way it's supposed to work
so it's a bug, rather than odd planning
neil 11:11 Then the bug is in NpapiPlugin::NewStream
taxilian 11:11 neil: just do a normal checkout of firebreath, put your changes in, and you can go from there
neil 11:11 Where it does "s->setSeekable( seekable );"
taxilian 11:11 no clue; I haven't looked through it yet =]
neil 11:11 That's fine - that's where it sets it incorrectly. I simply don't do it. I think it probably should be refactored so that a stream is only set to seekable if you requested it AND the server can support it
taxilian 12:11 I believe that is what Matthias intended
amackera 13:11 gnu screen is a really awesome tool
kylehuff 13:11 screen is probably my most used utility...
taxilian 14:11 amackera: yep; I use screen *all the time*
michiel_unhosted 14:11 hello taxilian! do you think if i write an openssl plugin, that people would reuse it? you talked about security on twitter, i didn't really understand that point
taxilian 14:11 hey
well, it's hard to say
so the issue with openssl in a web plugin
is that to sign something, you need a private key, right?
so you have to make sure there is no way that someone could hijack your plugin to steal someone's private key
stepping back a bit, though, what is your use case?
michiel_unhosted 14:11 ok sorry. what i want boils down to end-to-end encryption for Diaspora (the "open-source facebook rival" hype). so instead of client-to-server transport layer encryption, i want payload encryption.
so yes, i need a private key to exist inside javascript.
taxilian 14:11 well, throwing aside the fact that as a facebook employee I probably shouldn't be willing to herlp you... ;-) (totally kidding)
yeah; that's tricky
michiel_unhosted 14:11 but i already accepted that for other reasons, to it's not a problem.
taxilian 14:11 really tricky
because if you have the private key in javascript, then you've got the possibility that malicious code could somehow steal it
michiel_unhosted 14:11 yes, so make sure there's no malicious code
the code is going to see everything i type, anyway
there's no way around that
taxilian 14:11 that's easier said than done, but set aside that for a moment; why do you need to encrypt the payload?
michiel_unhosted 14:11 (i didn't know you were a facebook employee btw, haha, sorry! ;) )
because i want to post it to a server that i don't fully trust
taxilian 14:11 lol. no problem =] I can't give you any facebook technology, obviously, but I can still answer questions
ok; I assume you are already familiar with the basic requirements of having a trusted CA and some way to validate that the certificates can be trusted, etc al, right?
michiel_unhosted 14:11 yes, i was thinking friend-of-friend web of trust sort of thing. that's a separate issue that other people are dealing with :)
taxilian 14:11 ok; then we focus on just the plugin side of things
ok; well, if the server is untrusted, then you have to store the key locally, correct?
michiel_unhosted 14:11 yes
well
if you store it remotely, then it needs a passphrase
but in usable form it would never exist outside the browser-plugin-js sphere
my main question is: do i write a plugin for my whole thing, or just for openssl?
taxilian 15:11 hmm. well, if you make it seperate then you do open the possibility that others could use it
but whether people would actually use it or not... well, I don't know
in general, people don't like installing plugins
a good rule of thumb is that if you can do it any other way, don't use a plugin
because the need to download and install, the paranoia that everyone has about security issues, etc, it all adds up to losing users when you present them with the need to install the plugin
that effect is lessened when it is a more controlled, focussed userbase
what else do you need to do with your plugin besides openssl?
michiel_unhosted 15:11 the rest, i can do in javascript
taxilian 15:11 then you probably may as well do it as generic as makes any sense, release it open source, and see if anyone else wants to use it
michiel_unhosted 15:11 it's handling the semantics of transparently encrypting before you send, decrypting after you receive
great
i think if it would become 'the official openssl plugin' then people would be more likely to install it then if it is 'the unhosted plugin'. wouldn't you think?
taxilian 15:11 most likely, yes
michiel_unhosted 15:11 in your case maybe that's different. but i'm just a silly small open source project
taxilian 15:11 the only question is whether or not openssl would be interested in a plugin =] and you'd have to ask them
michiel_unhosted 15:11 and openssl is a much more trustable name
i will
taxilian 15:11 most certainly
michiel_unhosted 15:11 good point, haha :)
I am surprised so few people seem to be doing this.
taxilian 15:11 well, there are people doing it
SofwareMaven is working with email encryption
but most people when they have a need like this it is much more specialized
and often they aren't interested in making it open source
michiel_unhosted 15:11 i understand
yeah, it would be like the 'Bank of America' plugin
and then it would be more trusted than 'the openssl plugin'
taxilian 15:11 so if you check out the dev repo (the 1.4 branch) I already have an openssl firebreath_library in there
on windows it will statically link, mac and linux dynamically link
michiel_unhosted 15:11 ooh jolly!
that's great news
taxilian 15:11 so you just have to add "add_firebreath_library(openssl)" in your PluginConfig.cmake file and you should have everything you need
michiel_unhosted 15:11 excellent, i'll get on it!
taxilian 15:11 it might need to be tweaked; I'm using it for a very specific task, so I may be missing something or whatnot
michiel_unhosted 15:11 ok
taxilian 15:11 but it's a starting point
michiel_unhosted 15:11 great! i will let you know how it goes. you have been a great help!
thanks a lot
taxilian 15:11 no problem. feel free to give us a little publicity as you get things going as a thank-you ;-)
and when you get things up you're welcome to put a link to your project on the firebreath page
michiel_unhosted 15:11 obviously! :)
taxilian 15:11 there is a "people using firebreath" section
michiel_unhosted 15:11 i'm looking forward to it :)
taxilian 15:11 I look forward to seeing what you come up with
glad we finally made it to the chatroom at the same time =]
michiel_unhosted 15:11 yes!
now, i'll go for a walk and see the sunrise... it's 6am here ;)
taxilian 15:11 hehe. where are you located?
michiel_unhosted 15:11 Bali
Indonesia
i'm an open source project
taxilian 15:11 cool. I have a cousin who spent some time in that area
I think most of his time was close around Jakarta, but I think I remember him mentioning Bali as well
michiel_unhosted 15:11 while working on this project, i'm living off my savings, so i moved to a tropical island :)
taxilian 15:11 hehe. smart =]
michiel_unhosted 15:11 i would love to see Frisco one day though :)
taxilian 15:11 Frisco?
michiel_unhosted 15:11 i though people called San Francisco Frisco and that that's where silicon valley is?
taxilian 15:11 they might. I live in Utah, so I don't know =] Facebook is located near San Francisco, though
I work remotely
michiel_unhosted 15:11 haha ok.
I almost called my project Utah.
taxilian 15:11 really? why?
michiel_unhosted 15:11 i don't remember exactly what the abbreviation was, but it was a pun on this other cool project, tahoe-lafs, with tahoe being a lake, and Utah having a salt lake
anyway
taxilian 15:11 lol. ahh =]
michiel_unhosted 15:11 nice talking to you! i'll go play with "add_firebreath_library(openssl)"
taxilian 15:11 good luck
michiel_unhosted 15:11 cheers!
taxilian 15:11 remember you need the dev 1.4 branch