OpenCPN PlugIn Development

[seandepagnier]

I personally don't think we should have any proprietary plugins. Besides violating the GPL, there is no overall advantage to using proprietary plugins to anyone, and unfortunately a lot of people think it is ok. We can discourage this, and aim for completely free software. It's possible to persuade others to open their sources if it is required, otherwise their plugin should not be available for download from the opencpn site.

The plugin manager could allow you to enable/disable plugins, select library files from any location, and possibly provide provisions for plugin options.. but the plugin could provide it's own option menu when loaded too. If we need sub-plugins (plugins which depend on other plugins) it can be added pretty easily.

[bdbcat]

Hello PlugIn'ers (is that a word?)

In anticipation of continued PlugIn development, and to disconnect the PlugIn releases from the OpenCPN Release cycle, we are making the following policy change.

Two current PlugIns (Grib and Dashboard) will be included in the official OpenCPN git repository, and track OpenCPN Release cycles.
All other PlugIns, existing and under development, will participate in the opencpn.org PlugIn Download Plan.

What is the PlugIn Download Plan, you ask?
Key Points:
1. PlugIn developers may apply for and receive the ability to upload their released binary files to a new section of the opencpn.org Download page.
2. Users may download and install any PlugIns they choose directly from the opencpn.org site.
3. PlugIn developers will maintain and post links to the source code for any uploaded PlugIns. This is open source, after all.
4. This mechanism will apply to free PlugIns only. PlugIns requiring a fee for downloading will be hosted independently by their developers.

I hope that this plan will ease the release syncronization problems we have seen so far, and allow users to customize their OpenCPN experience to provide the best individual environment possible.

Please monitor this thread for information concerning PlugIns available for download. Check out the new opencpn.org PlugIn Download pages. Feedback on the Plan, or anything else, is encouraged.

Mucho gracias to Will (manimaul) for implementing the code necessary to support this Plan on the website. Nicely Done!

Thanks to all
Dave

[ActiveCaptain]

Originally Posted by bdbcat

4. This mechanism will apply to free PlugIns only. PlugIns requiring a fee for downloading will be hosted independently by their developers.

What if the PlugIn is free but not open source?

[Netsurfer]

Originally Posted by bdbcat

2. Users may download and install any PlugIns they choose directly from the opencpn.org site.

The latter is no problem. But including them on a page within the Drupal script seems not to be the best idea to me.

Downloading and installing plug-ins should be as simple as possible for a user. IMHO that means that this process should be "automated" by a script.
Therefor some kind of versioning system should be available to check if there is a newer version of a plug-in. Also each plug-in should be somehow marked for which OS it is working.

So one feature request hereby is to implement a mechanism into OCPN which is able to handle the process of donwloading and updating plug-ins. And if possible it would be nice if newly downloaded plug-ins could be enabled without the need to restart OCPN.

Letting the user do all this manually is not very user-friendly in my opinion (because there are lots of other possibilities).

In my opinion setting up a separate script on opencpn.org for the plug-ins would be much better. Additionally there should be a script running which allows for simple requests for

• available plugins
• suitable OS
• version/ date

IMHO you can see some good examples of user-friendly plug-in handling when regarding any modern browser like e.g. Firefox.

Gunther

[bdbcat]

Gunther....

What we need is a PlugIn that is a PlugIn manager.

It would know how to poll the opencpn.org site for updates, do the install, revert to previous versions, etc, etc...

Good idea! Any takers?

Dave

[bdbcat]

Jeff...

All OpenCPN PlugIns are open source. That is they way they are, established by the form of the API.

PlugIns may call (by simple fork and exec, or equivalent) other programs, which need not be open source. I think this is the case that most interests you.

The OpenCPN Download Plan will host the PlugIn and all extra data and/or programs necessary to exercise the PlugIn's function normally, if such data and/or programs are not generally available on the user's system.

Note that this is an opencpn.org policy decision, and not directly a consequence of the licensing structure chosen for the application or any of its its PlugIns.

Here is a (semi)contrived example:

I have a proprietary Windows Program (called emon.exe) which read the state of all my engine sensors. When executed, emon.exe reads the sensors and creates a data file in my /temp directory. I create an OCPN PlugIn that periodically triggers emon.exe, reads that data file, and shows the time history of the engine data in an OpenCPN sub-window.

So, opencpn.org may host the PlugIn, which would be GPL licensed. A binary image of the closed-source emon.exe executable could also be hosted. We need not, and would not host the necessary Windows runtime dlls, also closed-source, since they are generally available on the target system.

PlugIns are a gray area of open source distribution and licensing, but there are some precedents.

My reference is:
Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation (FSF)

Anyway, as I say, the licensing discussion of PlugIns is separate from the policy decisions related to the opencpn.org Download Plan. I personally would be happy to see your PlugIn play in this arena.

Thanks
Dave

[Netsurfer]

Dave ...

Originally Posted by bdbcat

What we need is a PlugIn that is a PlugIn manager.

It would know how to poll the opencpn.org site for updates, do the install, revert to previous versions, etc, etc...

Good idea! Any takers?

Hmmm ..., a plug-in for managing the plug-ins?
And this one could be dis-/enabled like any other plug-in?

I am more of the opinion that a "plug-in manager" should be an integrated part of the core.

What will be the "most often" or "normal" way for the majority of users?
IMHO it is:

1. Download OCPN setup file (where one needs to be online)
2. Install OCPN

So the first place "to handle" plug-ins should be at installation time (and I had this already in mind when creating the new Windows installer).

As I assume that most of the plug-ins are relatively small in size I guess most users will download them all at first no matter if they use it or not.

So once they have installed OCPN (and at least downloaded the plug-ins that were available at that time) there needs to be some kind of mechanism which

• checks for new plug-ins
• checks for available updates/newer versions for existing plug-ins
• downloads new plug-ins (self-extracting archives might be the best for Windows) and extracts them to the right place

One of the problems I see when doing all this also by a plug-in is, that you'll have (right from the start) a plug-in that has to be treated other than any other plug-in.

Another reason why I am thinking that OCPN' core should have a "connection manager" with a well defined API is that web sources are increasing.
Besides the new plug-in download system there is a growing number of other (useful) resources like Pavel's weather forecast maps (because they aren't available as GRIB files) and I offer some current maps (because OCPN's GRIB plug-in can't display the available GRIB files) and of course the large number of GRIB file sources itself.

So IMHO it would be another great step forward if users were able to handle all these sources from within OCPN (for the GRIB files this has been a pending feature request for a long time already).

If there were a "connection manager" it should be accessable by all parts of OCPN especially by the plug-ins themselves (e.g. for the updates or for downloading GRIB files by the GRIB plug-in).

I cannot see how this could be properly achieved by a (another) plug-in.

BTW: To display/ list all available plug-ins additionally on a site within opencpn.org's Drupal site is way easy. But if it would be the only place with all the needed information available I guess it would be hard to setup a nead system. Have you ever tried to send a HTTP request to Drupal for getting some information about a stored resource? Next thing is that we depend on another third-party script (without any needs). So just setting up our own (very) small (MySQL) DB for managing the plug-ins seems much more ideal to me.

Thanks,
Gunther

[bdbcat]

Gunther....

I hear what you say.

I am looking around for the army of coders necessary to implement same.

See any?

Dave

[Netsurfer]

Dave ...

Originally Posted by bdbcat

I am looking around for the army of coders necessary to implement same.

Hehe ..., must think of the old Status Quo song "You're in the armay now ..., you're in the army - now!"

See any?

Of course!

• Will could do the setup (script + DB) on opencpn.org
• I can do the Windows installer part
• and you'll do the rest ...

Sounds fair, doesn't it?

Taking it seriously we do not have all ready for the next stable (2.3.0) release. And we could certainly start with any other way/ system of handling these things.

But I still believe that a simple, fast and "future-proofed" system as described above should be the long term goal (so developing time with beta 2.4 and maybe it's ready for production release in 2.5).

So it might be a good idea to discuss and determine the system which should be established at the end. And for the short term let's see how to do things with as little effort as possible.

How sounds this to you?

Gunther

[cagney]

Good move with the plugin policy change and the connected development on opencpn.org.
At the moment there is exactly one plugin that is not default, and has to be upgraded separately, the promising but still buggy celestial plugin. Hopefully there are more plugins in the pipeline, or as ideas floating around. Let's see how this pans out. After all, plugins has really just been introduced......
I can't see a great need for a plugin manager at this time. Once there are more than a handful of good plugins, all users will have a better handle on what is needed from a manager, as well as if/when such a development is needed. Sure it is good to plan early for future needs, and netsurfer has some good ideas. But ... to me it is a bit like putting the cart in front of the horse, with just one plugin to manage..........

Thomas

[Netsurfer]

Thomas ...

Originally Posted by cagney

I can't see a great need for a plugin manager at this time.

But later ...?

Once there are more than a handful of good plugins, all users will have a better handle on what is needed from a manager, as well as if/when such a development is needed.

I disagree. Why should this depend on the number of available plug-ins?
What things could be different if there is one or a dozens plug-ins?
IMHO the "system" is always the same.
And plug-ins are no new invention by OCPN. I am quite sure that everybody got already in touch with them. So it shouldn't be that complicated to define the needs for such a system concerning the known "parameters" for OCPN.

Sure it is good to plan early for future needs, and netsurfer has some good ideas. But ... to me it is a bit like putting the cart in front of the horse, with just one plugin to manage..........

Sorry, again I see it the other way round.
Starting a new "service" without having possible future needs already in mind may often lead to undesirable development. And in the end you have more work than if you'd done it right the first time. At least it should put the later system no obstacles in the way ...!
And to avoid this you should know about the later system before you set up anything.
User experience is also a point that should be considered - it's not very pleasent if the general handling/ beahviour of a functionality changes (drastically).

And as I wrote before: We certainly do not need to start with a complete "Plug-in Management" system. But we should first think about what we want to have in the end (whenever this will be - doesn't matter) and watch carefully to not put any obstacles in the way meanwhile.

I mean what's the difference whether you set up a plug-in page on the website or build its own database (with a script which is able to answer any kind of requests later)?
And for the beginning they could also be listed on such a site. This could be done automatically and doesn't take much efforts.

But I don't want to give the wrong impression - to me it does not care in the end. I am just thinking what will be best for future development of OCPN (with special concern on usability ).

Gunther

[manimaul]

Jeff,

You can find the guidelines for publishing your PlugIn on OpenCPN.org here. I too would be happy to see you create a PlugIn.

Developers should have the prerogative to publish their code under whatever license they want. Open source and propriety software can be mutually beneficial so long as they respect each other.

I look forward to the GPLv2 or later licensed "Fork & Exec Proprietary Interface PlugIn". Perhaps you could be the first to pave the way for proprietary interaction with OpenCPN that would bring data and features otherwise out of reach.


Will

[ActiveCaptain]

I'd be interested in creating an AC PlugIn if a DLL it linked to was private. The fork to exec is unacceptable to me.

I don't get how binding OCPN to Windows DLL's is allowed under these rules as I understand them. Does OCPN ship the source to gdi32.dll and other Windows libraries?

[bdbcat]

Jeff...

In answer to your second point:

From the GNU FAQ Page:

What legal issues come up if I use GPL-incompatible libraries with GPL software?

Both versions of the GPL have an exception to their copyleft, commonly called the system library exception. If the GPL-incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them.

GPLv2 says the following, near the end of section 3:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

We have this language in our OpenCPN license.

Dave

[Netsurfer]

Dave ...

I got a few questions about the Plug-in system:

1. Is there already a solution for localizing plug-ins?
   (please also see FS#200)
2. How are plug-ins delivered (for each OS)?
   AFAIS each plug-in has at least one DLL file, but might also has subfolder(s) and additional files.
   AFAIK it is possible to build self-extracting archives with automatically running an installer (silently) - see: Info-ZIP Home Page
3. How is ensured that there are not two mutually incompatible plugins are activated at the the same time?
4. If plug-ins are fully localized where comes the plug-in name from and how to find the download link/ location?
   I already proposed a system by assigned IDs which simply overcomes any localization problems.
5. How does the versioning system of the plug-ins looks like?
   And where to get these informations?

Thanks for any information,
Gunther