What is difference between webpg-npapi, webpg-firefox and webpg-chrome projects?

[nick7ikin]

Hi, Kyle

Could you please explain the difference between these projects? Do they have common parts, which ones?

It is interesting, cause NPAPI till the recent time was acceptable for both FF and Chrome. So it is interesting why did you develop webpg-firefox and webpg-chrome as separate projects.

[kylehuff]

Fair question(s) -

webpg-npapi is the back-end API to GnuPG. It is a browser plugin that provides the interface to the crypto and key methods of GnuPG. It is an entirely separate project because it was designed for use in products other than WebPG. It is also written in C/C++, so even if no other projects used webpg-npapi, it makes sense to me to have it a separate project.

As for webpg-chrome vs webpg-npapi, originally they were very divergent (the firefox add-on was predominantly composed in XUL). I have since merged the code-base as I've moved away from XUL usage at all. The only reasons why they are still separate projects are listed below

1.) the build process is still very different (XPI vs CRX)
2.) The directory structure for the plugins is quite different (that will go away when WebPG moves to native-messaging for chrome and JS-CTYPES for mozilla)
3.) At the time, it was less confusing for the mozilla add-on review team to perform their code review.

Eventually my goal is to merge the two projects entirely, but given that doing git push master wpgff:master is so damn easy, that is really rather low on my list of priorities. However, webpg-npapi will remain a separate entity (used as a git sub-module) and may even get renamed to reflect the support for NPAPI, native-messaging and JS-CTYPES.

That is the grand overview, the specific parts that are different about webpg-chrome vs webpg-firefox is -

• The directory structure of the plugin objects
• The webpg-firefox repository has the "XULContent" directory which contains the XUL needed to load the plugin object and inject the UI elements into thunderbird

Otherwise they are identical. And yes, I realize that webpg-firefox should have been named webpg-mozilla, since it supports Firefox, Seamonkey and Thunderbird (and a few other mozilla based products not sourced from mozilla).

Clear as mud?

[nick7ikin]

Thank you for explanation. Seems clear

Let me check if I understand correctly. Google Native Messaging requires separate (host) application that extension will be able to connect via stdin/stdout. There is also way to communicate via WebSockets, but it requires to run server somehow (manually by user or via auto-run). So it'll look like this

GNU Gpg (Gpg ME) <------> Host App <--Native Messaging--> Chrome Extension (JS)

Does it correspond to your vision how it should work?

[kylehuff]

Yes, except the communication with the chrome extension and the native messaging host is initiated from the extension. The native messaging host can only send data to the extension in a response to a request.

[nick7ikin]

Is it a problem if host cannot establish connection by itself? I can't guess situation when it can be needed.

Actually there is workaround with runtime.connectNative (http://developer.chrome.com/extensions/messaging#native-messaging), that can be used like long-polling in web. So extension opens port and it provides messages in both direction until closed.