IRC Log Viewer » #firebreath » 2012-10-11

IRC Nick Time (GMT-7) Message
liyu 04:10 how can i add a c++ source file to firebreath
is there any one who can help me ?
dtiedy 11:10 Is there a way in filebreath's http stream handlers to force it to check the server for a file and not use the local cache? Obviously I could no this by adding a random querystring to the URL, but I was hoping to not have to do that. I set cache=false in the host->createStream call and also in the FB::SimpleStreamHelper::AsyncGet( m_host, uri, callback, false ); function, yet I see it still pulls from local cache in Chrome rath
taxilian 11:10 there is no way w/ npapi
so short answer is no
you can probably add a get parameter as a cache breaker
?ts=3242431212 with the timestamp or something
dtiedy 12:10 correct, I just didn't know if that can break CDN's. I mean I know that technique has been used as DOS attacks against CDN's. Since CDN's are never dynamic than I'd hope any edge network would strip off any querystring and use it's cache without pulling from a farther away network. I've just read a few papers on it, but I'd assume that most CDN companies handle this correctly as this is their business
taxilian 12:10 it depends on the CDN and how they do it
dtiedy 12:10 Thanks. I was just confused by the cache parameter to the streams and was thinking maybe I was doing something wrong.
It has been the source of a lot of issues on our project
taxilian 12:10 yeah; I didn't create that API originally
and I only recently discovered that the cache parameter is only used on ie
reichi 14:10 taxilian: is my observation right that IE creates a "global" with the id of any <object> tag?
<object id="video" ..... />
taxilian 14:10 actually IE creates a global with all ids
reichi 14:10
taxilian 14:10 but I don't recommend you use it
reichi 14:10 oh
i don't want to
but i stumbled upon sites that do so...
which confused me in the first place
taxilian 14:10 it's an old usage; firefox used to do the same thing (maybe still does?) but it was deprecated quite awhile ago
in fact I think it even works on Chrome (but causes a deprecation warning on the console)
reichi 14:10 nope firefox doesn#t seem to that anymore
it actually didn't work on chromium i think
it's not important i just wanted to be sure id din't miss anything
taxilian 14:10 just tried it on chrome on windows
works fine
reichi 14:10 it didn't wokr on my linux chromium
taxilian 14:10 may depend on the id, though; some could be reserved words and thus won't work
reichi 14:10
in that case it doesn't seem to work
but it's called video
but anyways
taxilian 14:10 that might not work because video is a tag name
reichi 14:10 thx for helping out :)
taxilian 14:10 yw
reichi 14:10 yah, that's what i assume, too
JuanDaugherty 15:10 I think I found why Chrome isn't starting my plugin. There's no filetype associated.
taxilian 15:10 hmm. interesting
there is a variable in PluginConfig for that
JuanDaugherty 15:10 innit?
odd that it just does nothing, not try to down the file or display a message or anything
it also doesn't seem to pickup when I unregister debug and register release
and the wix installer installers in user appdata roaming which seems odd too
but chrome sees it there so must be a right place
taxilian 15:10 it doesn't matter where it is installed
as long as the registry points to it
the reason it's installed in roaming is in an attempt to keep the registration with roaming profiles
JuanDaugherty 15:10 ah
taxilian 15:10 unfortunately while that works fine for NPAPI most roaming profiles discard any changes to COM registrations, so it doesn't work there
JuanDaugherty 15:10 by PluginConfig did you mean a cmake file?
taxilian 15:10 PluginConfig.cmake
in your project directory
if you aren't familiar with it you should definitely take a few minutes to look at it
it's one of the most important files in your project
JuanDaugherty 15:10 no I am but you didn't give a full file name
when was 1.7 tagged in the FB main github account?
taxilian 15:10 okay; if I say PluginConfig that's the only file I'll ever be referring to =]
1.7 hasn't been tagged
1.7.0beta1 was
and there is a 1.7 branch
but the branch has been there for monhts
JuanDaugherty 15:10 branched then
taxilian 15:10 months
and months
in short, a long time =]
JuanDaugherty 16:10 thx, cuts out a step; I was hoping those were in some sense guarded baselines, but I guess there's no such thing in FB
taxilian 16:10 my philosophy is to provide a simple solution for most cases, but leave as much room for customization as possible
JuanDaugherty 16:10 good approach
thebill 16:10 hi guys, i've got my plugin working, and trying to build an installer. I'm using VS2010 on Win7, and the instructions on arent working, i dont have an installer project. I've installed wix 3.6 and modified my env variables (removed the last '\')
how can i generate the installer project? re-running prep2010.cmd isnt generating that project
taxilian 17:10 wix 3.6 seems to have changed the default install location
you can either install 3.5 or add a WIX environment variable that points to the directory where wix is installed
thebill 17:10 i've got a WIX var set to C:\Program Files (x86)\WiX Toolset v3.6
taxilian 17:10 did you restart the command prompt you are using before you reran the prep script?
did you rerun the prep script after you installed wix?
thebill 17:10 may have used the same one without restartng... i'll do that now
taxilian 17:10 adding an env variable doesn't take effect until the shell is restarted
in some (hopefully rare) cases you may need to reboot entirely
thebill 17:10 ah! works. thanks for that! next question, i've got an external dll i want to include, any way to build 2 installers, one for x86 and one for x64?
taxilian 17:10 this is on windows?
thebill 17:10 yes
taxilian 17:10 why do you care about 64 bit?
thebill 17:10 I need to deploy both 32 & 64 bit installer versions of a 3rd party dll
its a driver for a webcam
taxilian 17:10 ahh
a driver
that's a wix question, really
it can absolutely be done, though
is it an actual driver?
or just a dll you link to?
thebill 17:10 a dll
taxilian 17:10 then you wont' be using the 64 bit one unless you are in a 64 bit plugin
so unless you need a 64 bit plugin for some reason, just use the 32 bit dll
thebill 17:10 ok, i'll try that, thanks
JuanDaugherty 17:10 on windows, is registering the dll sufficient to get the current browser coverage or is the msi required?
taxilian 17:10 msi is not required
it is highly, highly recommended
JuanDaugherty 17:10 so it does some optional stuff?
thebill 17:10 I've built my installer, i've got 3 files (release mode), a dll, msi & wixpdb. I want to deploy to web server, do i only need to upload the msi & give users that link?
taxilian 17:10 iit's an MSI
an MSI keeps a record of what it does so it can be reversed
it doesn't (usually) do anything that the regsvr32/selfreg stuff does, but it does it in such a way that you know what it did and there is very little chance that the uninstaller will miss anything important
whereas the selfreg you're just trying that I didn't make any significant mistakes
JuanDaugherty 17:10 what exactly do you mean by selfreg, manually running regsvr32 or programmatically running the dll registration api?
taxilian 17:10 selfreg is what you get when you manually run regsvr32
because regsvr32 just calls DllRegisterServer and asks the dll to self register
JuanDaugherty 17:10 as opposed the msi?
taxilian 17:10 either of the options you specified are exactly the same thing
the msi knows what selfreg would do and contains steps to do the same thing, but because of how an MSI works when it is uninstalled the process will be reversed correctly
JuanDaugherty 17:10 should be equivalent to regsvr32 /u unless I'm missing something. Either the paths are equivalent or they aren't.
taxilian 17:10 yes
it should be
so the difference between the msi and selfreg is that selfreg *should* work
and msi *will* work
JuanDaugherty 17:10 msi cannot undo what you're calling selfreg
it undoes what it does
taxilian 17:10 you are correct
the msi installer *does not use* selfreg
except to create the installer
not to install
and it's not me that dubbed it selfreg; that's what microsoft calls it in most of their documentation
JuanDaugherty 17:10 you should be clearer about the distinction between these processes, between simple regsitration of the dll and the wider registry affecting install process
thank you for enlightening me, I'm clear myself now
taxilian 17:10 I'm not clear that there is a difference
there is a difference between installing with a MSI and installing with selfreg
but they both install the same thing
just one does it in a reversible way, and the other has another call to reverse it; it's just a question of dependability
JuanDaugherty 17:10 that's false but don't have time to explain it
taxilian 17:10 sure
makes no real difference to me at the moment
JuanDaugherty 17:10 the diff is between a series of actions taken in only direction in a regular native code/ unmanaged program one of which happens to be dll registration
and the execution of a reversable script in an installer purpose built for that
even in the installer the programmer has to assure proper reversal
taxilian 17:10 sounds good to me. throw it on the wiki =]
actually MSI pretty much assures proper reversal for you
unless you specifically tell it not to
but anyway, I'm off for today
good luck