IRC Log Viewer » #firebreath » 2015-04-29

IRC Nick Time (GMT-7) Message
taxilian 08:04 walter_ good morning
walter_ 08:04 hi
walter_ 11:04 Taxilian - quick thing I noticed - not sure if this was intendet or not...
The plugin object that is created from Fire Wyrm - even if I check it's property, like:
if (plugin.readFile != null) ---> or if (typeof plugin.readFile !== 'unfedined') ---
it's not just checking if property exists/or not -- it's actually triggering communication to host process,like:
--> {"cmdId":48,"type":"cmd","c":1,"n":1,"colonyId":0,"msg":"[\"GetP\",1,0,\"readFile\"]"}
<-- {"c":1,"cmdId":48,"colonyId":0,"msg":"[\"success\",{\"$type\":\"ref\",\"data\":[0,18]}]","n":1,"type":"resp"}
I'm just wondering -if this is really required in this case?
taxilian 11:04 yes, that's intentional
yes, that's intentional
and it's required; there is no way to tell why you are calling that getter
and there is no way really to know what the value of readFile is in a synchronous way
so all property getters and function calls are async
walter_ 11:04 ohh
ohh
I thought that Fire Wyrm - is setting functions for functions - and getter/setter for properties ;)
I thought that Fire Wyrm - is setting functions for functions - and getter/setter for properties ;)
taxilian 11:04 nope
walter_ 11:04 but I see it's using only getter/setter
taxilian 11:04 getter for everything
there are reasons
there are reasons
they are moderately complicated
walter_ 11:04 ok, fair enought
ok, fair enought
taxilian 11:04 =]
=]
the promise that is returned is modified so it can be called like a function
the promise that is returned is modified so it can be called like a function
which hides the fact that it is a function
also means you can call a property, it'll just reject
walter_: just posted my response to your pull request comments. probably didn't catch everything
walter_: just posted my response to your pull request comments. probably didn't catch everything
taxilian 13:04 walter_: I'm back
whats up?
walter_ 13:04 The idea is not to use global window object at all... like window.createWyrmhole or mine window.wyrmhole.create() ....
taxilian 13:04 ahh, you're saying send the window message to create it, have it call back the function with the correct object
walter_ 13:04 I'm going to prepare firebreath object that contains wyrmhole - (similar to backgroudn example) - and that object will be passed to callback function from your load triggering idea
taxilian 13:04 hmm, that could work
walter_ 13:04 Also I changed the way scripts are injected...
Instead of injecting script by script .... content script will prepare special javascript text that contains all javascripts... And then it will inject inline javascript code once
That inline javascript will trigger window callback function
taxilian 13:04 I wasn't aware you could do that... but it sounds like it could make a lot of sense
walter_ 13:04 actually I'm done - I'm building demo projects to test it - and then I'll push it
taxilian 13:04 cool
walter_ 14:04 taxilian
I just pushed it...
please review & test it yourself...
You can trigger it like this: https://gist.github.com/wojwal/90b92d64a5756c3874ce
this is sample for FbTestPlugin
I'm leaving