August MidMonth update - Plugin progress

Note: this update is a bit 'developer focused'.  If it sounds very technical, it's not our normal style of updates, but the audience are developers that will want to extend Dynaframe in the near future.

I've talked about plugins for maybe a year now...actually implemented them and then realized that the way I did it wasn't something that a developer could efficiently build, and it was based on c#.  I scrapped the whole thing and started over about 2 months ago, and this month alot of that is finally getting to the point where I feel like it's going to ship.  I want to talk about the design and the progress, and what to expect this month and next (assuming we can ship on time and don't hit any bad hurdles).  Please note that other bug fixes are happening still, but the big feature for this and next month is plugins.  I think this post will make sense why...

Overall Approach and Design

Plugins for Dynaframe will be python based.  They'll consist of a python file or files, plus a json 'manifest' which will describe things like the author, name, and 'type' of plugin.  To start we'll have 2 types...'startup' and 'content'.  These files will be copied to a specific Folder in Dynaframe (which I'll work to expose via the file shares) and I'll work to get them into the store as well so they're easy to add/install (the file share would be for developers mainly).

Let's talk about the two types and how they differ, but also what POTENTIAL plugin functions they provide (I'm saying potential because this is all in development...we'll have to see what actually lights up and works)

"Content" plugins

Content Plugins are plugins which are called when a playlist is being formed.  This happens after every playthrough of a playlist.  What will happen is when a playlist is being formed, all folders that are chosen will be enumerated, and then python scripts will be run.  These scripts can call out to web content, get a list of content, and then call an http API to pass a JSON formatted list of the files.  This list will be appended to the current playlist.  This happens for each plugin.

This is a breakdown of what it'd look like as an example:
Say we have 2 plugins installed and enabled....
Deviantart
Pixabay

Let's say 2 folders are selected as playlists ('kids bday' and 'vacation photos').

The photos from kids bday will be loaded, then vacation photos, then the plugins will be called.  Deviantart lets say returns 30 photos from its source, and pixaby returns 50.

The resulting playlist will mix and match the local content and the internet content and display it.  It'll obey the Shuffle value...so if shuffle is on, it'll all be mixed up, otherwise it'll play in order.

After all content is played through....Deviantart and Pixabay will again be called and asked to return content.  We are working to see if we can pass a value to them to say that there is a 'second playthrough' so they can paginate and get the next page of content.

One thing to note...content plugins get called after a playlist completes. They don't HAVE to call an API or return content via JSON...they could manipulate anything they want via the HTTP APIs.  The main thing that makes them a content plugin is that they get called, are expected to exit, and only get called when a playlist completes or is being created.

Startup Plugins

Startup Plugins are going to be insanely powerful....they are started when Dynaframe Starts, and will be closed when Dynaframe exits.  That means they are able to run in the background the entire time.  This is powerful because they can at any time call any of the 'control' aspects of Dynaframe and enhance it.  Here's some examples of things we hope to do via this plugin system (or that you'll be able to create!)
- Cron job timers for turning the frame on or off at certain times
- Button extensions that allow for buttons to be added to a frame to control certain aspects
- Remote control plugins that allow for usb remotes to control the frame
- GPIO access to use other sensor (ambient light sensors to have the frames turn off for instance)
- MQTT listeners to control the frame
- Kodi style plugins

As you can see, may of the most often requested features will be something that we can develop as a plugin, keeping the core code base clean, and having the ability to easily remove features that may not be used by a user to save performance of the Pi (which we already stretch pretty heavily at times).  This will allow us to focus heavily on the engine, let the community develop and engage, and really elevate the project.

We're going to ask for patience as we work to get this right.  We have to be careful a rogue plugin doesn't destabilize the system.  We are getting there though. Today I saw 2 plugins pull content from 2 sources and integrate it into a playlist seamessly.

Configuration

Dynaframe sets a high bar for configuration...we want everything to be in the webUI and accessible.  Plugins will be no different...each will have an enable/disable via the webUI, and we're working so that plugin developers can have their own web UI for configuration.  This is tough when we don't know if the python process will exist, so the current plan is to save values to a 'shared json' file that the plugin and Dynaframe can both write to/read from.  We'll see how that goes...this is the part that I'm most nervous about, but we'll work to get it right.  I don't want developers to have to manage threads or open sockets to communicate from Dynaframe.  So a shared text file seems the simplest solution.  We'll see.

Thanks for reading.  We continue to dev like crazy on it. We have some bugs we'll need to go visit here in a bit but overall we feel like we're making positive progress each month.  Thanks for supporting and going on this journey with us!

Joe and the Dynaframe Team