Plugin concept changes - disruptive

A place for developers to discuss development of OSA
Post Reply
Message
Author
Vaughn
Site Admin
Posts: 1432
Joined: Thu May 13, 2010 2:17 pm

Plugin concept changes - disruptive

#1 Post by Vaughn » Fri Jan 22, 2016 1:52 pm

Plugins were one of the first parts designed in OSA and have not changed since. Some changes need to be made to evolve the plugin system. I am not talking about the plugin's underlying technology, but rather how OSA handles them.

1. Computer Name property was used to determine if the plugin can be distributed or has to run under a single computer, yet every plugin is on a computer and that needs to be used to store that information, not determine if is can run on other computers.

2. System Plugin property does nothing and was mean to keep users from uninstalling or deleting core plugins. I am not sure this is needed.

3. Containers should be used to map plugins. Making the computer name field obsolete. If every plugin sets its Container to the service running it, and that service has its container set to a computer, and that computer has its container set to which room the computer is in, then we have a full map of where every plugin is.

This will cause discomfort in testing and will have to update existing data automatically where possible and manually where it is not, hence my warning of the trouble I am about to kick up =)

Automate
Posts: 1691
Joined: Sat Dec 11, 2010 1:44 pm
Location: US

Re: Plugin concept changes - disruptive

#2 Post by Automate » Fri Jan 22, 2016 3:32 pm

It's been a while since I've run OSA in client / server mode but as I remember it, only the server installed the MySQL database. When installing the client you had to point them to the MySQL database on the server. If you installed a plugin on a client all the configuration was stored in the MySQL database like any other plugin. Only the executable DLL and associated files were needed on the client. When either the server or client service started they checked the central database for which plugins should run on computer running the service. In this way properties and events would act the same regardless of which computer was running the plugin.

Vaughn
Site Admin
Posts: 1432
Joined: Thu May 13, 2010 2:17 pm

Re: Plugin concept changes - disruptive

#3 Post by Vaughn » Fri Jan 22, 2016 4:43 pm

You are right about MySQL being centralized. But Plugin Version, Author, etc was never stored in the DB and was being read from the osapd files locally on each machine. Which is why the plugin web page only showed plugins on the main service and not client services. Now the plugin page can just pull the plugin list for all computers/plugins from SQL instead and not lose the local data from the osapd files as the service will update the sql properties as it reads the osapd files.

The Service/Client Service did not even know their own object names, now they do and pass it to the plugins, so they can set their containers automatically.

It doesn't appear the Service was updating its object when stopping (since it didn't know what it even was).

So far it looks way better, and works well enough I don't think we will even need a plugin page at all. I am setting up a client machine to test it all. And I will definitely make a new video covering this topic alone.

Vaughn

Vaughn
Site Admin
Posts: 1432
Joined: Thu May 13, 2010 2:17 pm

Re: Plugin concept changes - disruptive

#4 Post by Vaughn » Sat Jan 23, 2016 4:38 pm

Notice to Plugin developers! (Wiki will be updated to reflect this when done)

All Plugins Must:
Use ON/OFF States/Methods/Events. The ON/OFF method for plugins is used to start and stop them manually.
Have the Version and Author properties, which will hold the data from the osapd file.
Have the OwnTypes() subroutine and automatically set the owner for their plugin object type.


Notes:
* Manager and WebUI\Plugins no longer display or control plugins. They are standard OSA objects now and are controlled by the Objects page.
* Service seemed to mix Enabling and Starting plugins. Enabled (generic object setting) determines whether the Plugin tries to start automatically with the service only now. Start and Stop methods on the plugin works separately from the enabled property. Starting a plugin will not enable it...


I will update this as I am just starting on the Client Services now and will address naming conventions and the computer property next.

Post Reply