Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native Messaging #31

Open
adapap opened this issue Mar 13, 2020 · 2 comments
Open

Native Messaging #31

adapap opened this issue Mar 13, 2020 · 2 comments
Labels
question Further information is requested workflow Automation, testing, and configuration

Comments

@adapap
Copy link
Collaborator

adapap commented Mar 13, 2020

The latest changes in #29 retrieve Duckbill information by opening a new tab and performing browser/DOM manipulation to update the local storage and then display the change. This process works; however, it is inconvenient for the user for two reasons:

  1. It requires that a new tab is opened and waiting for the process of authenticating and parsing the DOM to complete in order to extract the data
  2. Closing the tab at any point causes the process to fail, and it is slow because each page is rendered (loads its content)

I found a solution to these issues which would drastically improve the convenience to the user through native messaging. This allows the extension to communicate with a native application, which in our case, can be any external executable. Here are some outcomes from using native messaging:

  • An external application can be written in any language
  • Must be installed by the user (from what I gather) and the path must be known by the extension
  • If using an executable, must support multiple outputs for different operating systems

Using native messaging will allow us to use a headless browser and simulation through Selenium webdriver. This means that the user can click to check their Duckbill balance, and the same process of web scraping can be done in the background without any interference with the user.

I'm open to any discussion regarding this integration.

@adapap adapap added question Further information is requested workflow Automation, testing, and configuration labels Mar 13, 2020
@dyc3
Copy link
Member

dyc3 commented Mar 13, 2020

Disagree about convenience to the user. Making the user install something else in order for the browser extension to work sounds terrible.

@adapap
Copy link
Collaborator Author

adapap commented Mar 13, 2020

From further research, it looks like any executable can be bundled with the distribution. This means we have to choose a language that will compile into an executable, provide one for each Windows, MacOS, and Linux, and run it depending on the platform architecture (which the extension can detect). Here is an example repo which uses Python, but uses a shell script to install the application.

I think Golang and C++ are good options for a native script, and potentially Python.

Edit: It looks like the above repo is derived from Chromium example source code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested workflow Automation, testing, and configuration
Projects
None yet
Development

No branches or pull requests

2 participants