IRC Log Viewer » #firebreath » 2013-12-21

IRC Nick Time (GMT-7) Message
jshanab 05:12 I have been reading up on and watching videos on the whole pepper,salt and npapi war. Am I correct in understanding that if you have a closed source dll or so that you depend on, you are hosed in the nacl world? you have to wait until the creator of the library re-compiles in their sandbox. (even then only if it does not need something nacl does not provide)
While I understand and complement them on what they have done, they already had a secure isolated solution for the continued use of legacy NPAPI plugins. This latest tactic kinda forces users to change browser. The one piece of the puzzle that is still unclear is how the web page interacts with a pepper/nacl plugin.
taxilian 07:12 jshanab: with just NACL that is correct. Their solution for a closed source dll is Native Messaging
jshanab 08:12 I am googling. In a lot of articles they "justify" it's deprecation with phrases like "Netscape era" which is funny. I guess C is Kernigh era. But they also say they are dropping it because mozilla will be blocking NPAPI starting dec 2013. Is that Accurate?
reichi 08:12 but not "totally"
afaik it's "click to play" now
as per default
at least it can still be reenabled
mozilla already started with that
jshanab 08:12 It seems they have all latched onto the use case for plugins as just browsing and games. What they can do with HTML5 (like the one line "pepper and nacl is a way for c/c++ to access the features of HTML and will follow that development". They are relagateing the other uses, for special hardware or protocols to 2nd class citizens.
reichi 08:12 I'm totally with you there
jshanab 08:12 I think this just pushes us back toward the old days of custom desktop apps, The "Thick Client"?
I could see making a shim that uses javascript to native messaging to C++ code as a way of adding chrome support to a Firebreath project, but I assume a windowed plugin would then be in trouble for graphics.
reichi 08:12 but obviously the leading people in terms of browsers are totally convinced npapi has to go
microsoft started off with it by essentially removing it from windows 8 apps, google announced it will completely remove it and mozilla already followed with that
and as opera is using blink, too
and as opera is using blink, too
it will most probably do exactly what google does on that
jshanab 08:12 Funny thing is, chrome already wrote the container with a render that communicates to the browser via IPC for NPAPI, the already have a secure way of supporting the legacy plugins. They don't need to get military on us.
reichi 08:12 well
I think it's totally stupid
jshanab 08:12 I hate the direction they went with mobile. we are now littered with apps and have to jump between them and the browser. They have to stop trying to make my desktop into an oversized phone :-)
reichi 08:12 :)
:)
jshanab 08:12 Opera is now based on chrome, I hear.
reichi 08:12 not chrome
but blink
which is the engine
which is the engine
jshanab 08:12 But MS has held on tightly to ActiveX right?
But MS has held on tightly to ActiveX right?
reichi 08:12 (a webkit fork without all the platform code)
no
there's no activex on windows 8 if you are not in desktop mode
and no npapi
and no npapi
so the truth is
everyone is moving away from npapi
jshanab 08:12 I can't get into windows 8. Most people I know have un-installed it.
reichi 08:12 and no matter if one likes that or not
i would guess within the next two years there will be no way left than dealing without npapi
jshanab 08:12 I like what google has done for nacl and pepper, architecturally, it is jsut this do or die crap.
I like what google has done for nacl and pepper, architecturally, it is jsut this do or die crap.
reichi 08:12 that's what google has become
jshanab 08:12 Yeah, A really overt about face. They are making Micrsoft look like saints.
Isn't this all tied to Mime types? Are those going away also?
So my question is. Is this a move to get rid of plugins or is it just a move to change to a new plugin technology?
reichi 08:12 npapi is bound to the object tag
essentially
essentially
so i guess browser will just not do anything anymore
for object tags
jshanab 09:12 That is a bit crazy. There are a lot of pages out there that use them. And they are still connecting flash and HTML5 up that way. I guess what they are doing is eliminating all but their own plugins. No DIY unless you are adobe,MS or some other big name.
reichi 09:12 flash is dying
which is a good thing
jshanab 09:12 Chrome is providing a plugin arch, just not NPAPI. If IE and Mozilla just drop plugin support entirely that will be a disaster. This could effect my day job. I work with security cameras and they each have their own plugin. Some only work in IE and only in compatibility mode. (no one would otherwise choose to use IE). This could mean we are gonna have to block windows from updating. Anyone...
...wanna guess how many security cameras are out there? Not like we can update the firmware on all of them to meet HTML5 only content. THese are servers that cannot "just be updated"
reichi 09:12 but there is a ppapi flash
jshanab 09:12 Agreed. DIe Flash Die
reichi 09:12 but obviously they are all very eager to enforce HTML5, WebGL & Co.
jshanab 09:12 Just when we thought we might gid rid of it the browser manufactures splintered off, Again. Sure we support HTML5 Canvas but we support codec A the other guys Codec B. grrr.
reichi 09:12 i think we're right in the middle of a big upheaval
i think we're right in the middle of a big upheaval
in terms of browser technologies
jshanab 09:12 My plugin allowed frame by frame stepping, zooming, reverse play clip export, etc. Try that with HTML5. I shared 90+ % of the code between Iphone,ipad,android, and my firebreath plugin.
reichi 09:12 i totally agree
but actually it's also obvious
but actually it's also obvious
that it would be better if that was not required
that it would be better if that was not required
and would simply work right away
so that's the upheaval i am talking about
jshanab 09:12 We have heard what they are getting rid of... but not what to replace it with. I want to write my code once. They seem hell bent on making me write it 5 times.
reichi 09:12 well
well
sucks
for us it just means at a certain point we'll have either backport things or just stick with the browser base we have at that point
but on an embedded device that's something you cann usually live with for quite a while
jshanab 09:12 I guess we wait for the other show to drop. One part of the google plan is portable nacl. So that is precompiled platform agnostic code runing close to native speed in a process the brower can communicate with. If the other browser manuf support that, then that could become the npapi of the next decade.
reichi 09:12 yeah, i read a tiny bit about that
and it sounded like it could help in some cases
but probably not in others
jshanab 09:12 That is what I mean. How do we stop a browser from updateing or install a previous version. That is not always possible and end users won't be able to cope with that.
I am just starting to get a picture of what their system is.
The native messageing that Taxillain pointed out looks promising. I could have it for example pull video frames from my proprietary protocol video server. This runs in an external process and transfers data thru messaging. If there is binary payloads, then a nacl part running in the sandbox can take that data and throw it on the canvas. Let me look in on that
reichi 09:12 well
well
luckily i don't have to paint anything...
for me it's enough to clear out the area where th eplugin resides
video is currently handled independently from the browser
so i have a modified webkit + firebreath to get the position and size
so i have a modified webkit + firebreath to get the position and size
and just move video there
and just move video there
the rest just works :)
jshanab 09:12 Thats good. I don't have to port my video plugin. The job ended and I am on to a new job. But I want to upkeep it and know that something this simple can be done. Looks like they are only supporting text based messaging at the moment. Thats pretty bad. The should of used their own Protocol buffers.
taxilian 09:12 to clarify a point there, Mozilla is not blocking anything but java by default yet
but they were planning to
my efforts may or may not have played a significant role in delaying that until things were discoverable enough, but as of the end of next month all major browsers will have plugins disabled by default with an info bar saying "do you want to enable …."
which honestly doesn't bother me at all, if they'd leave it at that
which honestly doesn't bother me at all, if they'd leave it at that
mozilla has not stated anything about actually dropping npapi support
I wouldn't say it's impossible, but so far they haven't given any indication of going that far, only Chrome as. I suspect Mozilla will wait and see how google's efforts go; if chrome drops it and has no major backlash then probably mozilla will too
jshanab 09:12 Right. Whew, They have always had a bit of that anyway. At least at install time.
If we could talk google into a faster system of moving data from native messageing like Protocol Buffers over ZMQ or something, then we could maybe even make a nacl/pepper plugin that includes our firebreath code. Hince your conversation with them in october I just saw. Instead of javascript calling our javascript API, it becomes javascript->nacl/pepper->message->{a firebreath "naclAPI" }...
If we could talk google into a faster system of moving data from native messageing like Protocol Buffers over ZMQ or something, then we could maybe even make a nacl/pepper plugin that includes our firebreath code. Hince your conversation with them in october I just saw. Instead of javascript calling our javascript API, it becomes javascript->nacl/pepper->message->{a firebreath "naclAPI" }...
...that then calls the plugin.
I do not know how this would work. I for example never found out how ActiveX just magically works in FB.
taxilian 11:12 jshanab: I don't think we could make it as transparent, but if there were a way to transfer binary data w/ native messaging we could maybe come up with something
jshanab 11:12 That would be nice. So does the activeX code call the javascriptAPI or does it replace it?
taxilian 11:12 actually there isn't that much difference between the general implementations
on ActiveX you have IDispatch, and on NPAPI you have NPObject
I wrote an IDispatch-implementing COM object to wrap a JSAPI object and I wrote a NPObject that wraps a JSAPI object
jshanab 11:12 So the JSAPI is always there. So We could concwivable write an objective C caller for an iphone, a JNI caller for android and then a pepper/nacl caller that has 2 parts to jump across the message boundry. Not to clean, Maybe having subclasses of JSAPI would help to reduce the layers when doing peper/nacl
taxilian 11:12 theoretically you could wrap JSAPI in almost anything, yes
jshanab 11:12 Wow, that would make for a wide scoping project. Last one to add is a widget container for the desktops ;-)
taxilian 11:12 hehe
hehe
I've even started pulling JSAPI into its own project, but havne't had time or really much real motivation to finish it
I've even started pulling JSAPI into its own project, but havne't had time or really much real motivation to finish it
jshanab 11:12 It is going to be hard to get jazzed up while the future is so up in the air