akipta / freedomotic

Automatically exported from code.google.com/p/freedomotic
Other
0 stars 0 forks source link

Plugin Persistence #198

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Set some plugins to running and some to stopped.
2. Shutdown Fredomotic
3. Restart Freedomottic
4. Plugins have not maintained state on running or stopped.

What is the expected output? What do you see instead?
Plugiins to be in the same state at startup as they were at shutdown.

Please fill this info:

Freedomotic Version: 5.3
Java Version: 1.7
OS Name: Linux
OS Version: Lubuntu

Please provide any additional information below.

NOTE: Remember you can attach the LOG FILE to this issue to help the defect
source identification.

Original issue reported on code.google.com by tim....@zoho.com on 2 Nov 2012 at 3:01

GoogleCodeExporter commented 9 years ago
This is done on purpose.
To make a plugin start on startup add this property to your plugin manifest

<property name="startup-time"  value="on load"/>

Original comment by enrico.n...@gmail.com on 2 Nov 2012 at 9:03

GoogleCodeExporter commented 9 years ago
That property will control plugin behaviour on startup.  It's not persistence.

An example...  Logger plugin is not started by default.  I have to start it 
every time I start FreeDomotic.  As a user, I want the Logger plugin to be in 
the same state at startup as when Freedomotic was shut down.

An example #2...  The REST API plugin starts every time.  I turn it off every 
time Freedomotic starts.  As I user, I want the RESTAPI plugin to be in the 
same state at startup as when Freedomotic was shut down.

I acknowledge, this can be done through the manifest either by the plugin 
itself or by a better plugin manager, but it should be in core.  Environment, 
Objects, Reactions all have persistence when Freedomotic is shut down and 
restarted.  Plugins should too.

Tim

Original comment by tim....@zoho.com on 2 Nov 2012 at 2:51

GoogleCodeExporter commented 9 years ago
I agree with Tim about the persistence of the plugin status.
It would not be very difficult to accomplish, is just store the data into the 
plugin configuration the same way objects are persisting its data...

Original comment by gabriel....@gmail.com on 11 Nov 2012 at 7:49

GoogleCodeExporter commented 9 years ago
Yes, it's easy to implement but I'm not sure it's the best option. I think this 
way the average user ends up in having "all on" with great consume of resources 
(eg: a webcam motion forget on). 

If a plugin receives a command (like a protocol integration plugin) while is 
off it turns on automatically, so only plugins with no "direct commands" should 
be started by hand. 

@Tim: I know what persistence means. From you description it seems you don't 
need persistence but a different "defualt startup state" and this can be 
achieved through the manifest. For example a developer may want the log to 
start by default, but I think the manifest way is better than the persistence 
way, this is what I mean with "done on purpose". The same for restapi, the 
average user should not care and have this always on, if an expert user knows 
what is doing it can simply delete the startup line from its manifest.

Let me know what you think

Original comment by enrico.n...@gmail.com on 12 Nov 2012 at 7:37

GoogleCodeExporter commented 9 years ago
Originally my request started out as persistence...  Same state at shutdown as 
at startup.
But... To your point, do-able, but probably not the best option.  Being able to 
control the startup behaviour will suffice.  I plan on putting this in my Tree 
Plugin.

This can closed.
Thanks
Tim

Original comment by tim....@zoho.com on 12 Nov 2012 at 5:28

GoogleCodeExporter commented 9 years ago

Original comment by enrico.n...@gmail.com on 22 Nov 2012 at 9:11