Re: Activex Firefox Plugin Download
Anna Pybus
I am trying to run the below code which launches notepad. IE tab is nice solution, but loading is slow. I gave the try to ff-activex-host.I downloaded the binary exe. I copied the npffax.dll to firefox plugin folder(C:\Program Files\Mozilla Firefox\plugins) . But, stillthe above code is not working. I am getting the message "ActiveXObject is not defined" in web console. Can anybody shed a light on this issue?. Please clear me of running this code. This is the code I am trying.
This is a firefox plugin that I was looking for since long time, you will probably say why we need activeX Firefox support ? Some Intranet applications require some functionalities that are already available as ActiveX. I had a ActiveX twain solution that I wanted to run on firefox, so finally I think this could be done using ff-activex-host.
The extension is developed by Leeor Aharon, IT Structures Ltd, makes possible to use ActiveX controls in Firefox and provides full access to the hosted control (events, functions, properties) based on the Gecko NPAPI. Concerning security :
When you're dealing with a lot of Linux servers, having a Linux client really comes in handy. My setup consisted of Linux Mint 18 and I could perform almost every task. I say almost because one task was always out of reach - viewing HP iLO console.
Two options were offered there - ActiveX and Java. While ActiveX had obvious platform restrictions, multi-platform promise of Java made its absence a bit of a curiosity. Quick search on Internet resolved that curiosity quickly - Firefox version 53 and above dropped NPAPI plugin system support and HP was just too lazy and Windows-centric to ever replace it. However, Firefox 52 still has Java support and that release is even still supported (albeit not after 2018). So why not install it and use it for Java iLO console?
First we need to download Firefox 52 ESR - the latest version still allowing for Java plugin. You can download these from Mozzila but do make sure you select release 52 and appropriate release for your computer (64-bit or 32-bit).
With the release downloaded, we can install it manually into a separate directory (/opt/firefox52) as not to disturbe the latest version. In addition to Firefox, we'll also need IcedTea plugin installed:
Of course, just installing is worthless if we cannot start it. For this having a desktop entry is helpful. I like to use a separate profile for it as that makes running side-by-side the newest and this release possible. After this is done you'll find "Firefox 52 ESR" right next to a normal Firefox entry.
Probably the most common thing that people want to do is to simply store a set of resources so that they are available without having to use the network. This is useful if you need quick access to the resources, or if you want to be able to access them even if the user is offline. Games are a very common type of application where this is needed. For example an enemy space ship might have a few associated images, as well as a couple of associated sounds, used when the enemy is moving around the screen and shooting. Today, people generally solve this by storing the images and sound files in a file system, and then store the file names of those files along with things like speed and firepower of the enemy.
However it seems a bit non-optimal to me to have to store some data separated from the rest. Especially when there is a solution which can store both structured data as well as file data. IndexedDB treats file data just like any other type of data. You can write a File or a Blob into IndexedDB just like you can store strings, numbers and JavaScript objects. This is specified by the IndexedDB spec and so far implemented in both the Firefox and IE implementations of IndexedDB. Using this, you can store all information that you need in one place, and a single query to IndexedDB can return all the data you need. So for example, if you were building a web based email client, you could store an object like:
Jonas has been hacking on web browsers for over a decade. He started as a open source contributor in 2000 contributing to the newly open sourced mozilla project. In 2005 he joined mozilla full time and has since been working on the DOM and other parts of the web platform. He is now the Tech Lead of the Web API project at mozilla as well as an editor for the IndexedDB and File API specifications at W3C.
What I really want is the ability to generate data and provide the user with a prompt to save it to a file, as if they are downloading it from a server. Like a PDF or a CSV file, generated completely client-side using javascript.
The filesystem API is really nice because, for example, it makes it easy to reproduce the file structure on your server, locally. You could, for example, make a request to the server, have the server zip up some resources, send the zip file down, and expand it into the same directory structure locally. This make it really easy to then use filesystem links in place of normal URLs to the server when your app is offline.
Applications normally access the local filesystem. If we want to
implement applications with web technologies (instead of, e.g.
in C++ or Java), we need to have a means to access the local
filesystem as well (beside other parts of the underlying OS).
Security had never been much an issue for traditional applications.
E.g. when installing Libreoffice (knowing that it does not contain
viruses) I did not think that it would disrupt my data or tamper my
OS. I.e. I trusted it when I installed it.
If web apps is just a technology for implementing apps, it should
do the same: ask me if I trust them, and if so, run with full privileges,
as normal apps.
So instead of one solution (FileWriter and Filesystem), you present two new, different ones, which not only you not yet fully support, but no other vendors support, whereas, for third feature, you do not have any solution whatsoever.
No API is ideal, if you can recognize that in Filesystem and in Filewriter, does not make them unusable, i would prefer, if you try to implement Filesystem first and then try yours ideas, and let us, developers, choose which one we want to use.
IndexedDB is implemented in two other browsers, but many people thinks its very hard to use, i intend to agree with that point of view.
And for some reason (oh, yeah, security and all that) only Firefox ask user permission to use it. For me (and many other devs and apps) is a big red flag, which is discourageable.
I agree that IndexedDB is hard to use. But not harder than FileSystem. And if all you need is to store resources rather than doing low-level file manipulation then IndexedDB seems outright simpler to use. But I concede to being biased :-)
However IDB keys things off of a much more complex concept of keys, which makes mapping a URL to an IDB location is much more difficult. And the values stored in IDB are arbitrary structured clones, which makes them harder to map to a network response.
Off the top of my head, you might be missing the one simple reason why people want the filesystem API: because they see Chrome as the most appropriate browser to target, perhaps with the easiest APIs to use, so they target that and want to do cross-browser easier than re-writing their work.
Most web developers are interested in a solution that works across multiple browsers. The FileSystem API is pretty far from this as last I heard only Google had expressed interest in implementing it. Meanwhile IndexedDB is implemented in three browsers with a forth one on its way.
I think part of the appeal of a file system api (without commenting on the Google spec) is it is very intuitive to work with if you are using files or interact with the file system. There are a wide range of web apps that do so or that attempt to do so from document editors to games that want to save state. If you are encouraging developers to work in offline mode, then they are going to be thinking about a file system api.
Of course, if you wanted to go with something really intuitive, browsers could implement some variation of the POSIX file api (admittedly adapted to JS constraints). Yes, it is not Webby but a large number of programming languages have realized that even if the POSIX file api does not necessarily fit their dominant paradigm, it is still useful to support it because most developers do not work with only one programming language and most will be familiar with this api.
For example, if the user would be allowed by the browser to empower a web app with raw POSIX, then that would unleash an explosion of databases running in the browser, orders of magnitude better and faster than IndexedDB.
You skirt the original point that innovation in the browser is currently top-down, whether it be FileHandle, WebSocket, IndexedDB, WebRTC you name it. Each of these is just a limited abstraction over an OS API. If Mozilla were truly open, it would expose these.
The file parts of the files that are stored in IndexedDB act just like a file which is stored in a filesystem. The only thing that is different is navigating the directory structure. So most things should feel exactly the same.
thx for clarifying this. I always assumed that you`ll need to load the complete file in memory in order to access it through a blob url. So now that i know better i`ll give it a try. If it works that might change my view towards this topic completely :-) So then it seems the only missing feature for me is the filesystem url scheme as you mentioned in your article. It would be really nice to be able to predict the urls of a certain blob somehow.
Any thoughts regarding folder uploads?
The filesystem api supports recursive iteration through folders/subfolders where you can get a reference to each object, optionally copying it into persistent storage in order to support resumable uploads etc.
Is this something that can be implemented without the filesystem api?
Thanks