Installer Plugin

I hate the MCV App store interface.
It also takes to long to get something approved.
Their web interface to source management is terrible.
The only thing it does right is to keep you from having a file name collision on Vera!

How about we define our own Plugin for installing code. Once this is installed it could handle subsequent installations from there.
This plugin would have the following standard options for each loaded plugin:
1) Install
2) UnInstall
3) Check for Update
4) Create Plugin Device

After installation, the list of options could be expanded to create additional, plugin specified installation steps.

We could implement Auto Update back to our home websites/repositories.

The idea is that as developers we can create a Zip file with all of our code, and meta information such as destination for files, startup procedures, optional/additional installation tasks …

This would be easy for users:
Single File to Install.
This would be easy for developers:
We do not have to document how to do things.
Or worry that someone doesn’t follow the install directions exactly.
Our own source code management.
We could have scripts that run on Vera that do things we would not even want a consumer to try.

Good Idea

It can also include a kind of RSS, or push feed inside the plugin to have informations about new versions, new plugins …

I have ressources in my company to host the future plugin repository.

Agree… is there ANY development of “App Store” at all?

I would like to see how many downloads there has been of my plugin for example… (ego thing… i know…) :slight_smile:

I think we could support multiple repositories …
We just have to define the interface between the plugin and the repositories.

Yes. Shouldn’t be too hard.

Cantral repo keeps a list of urls to distribuated “descriptor files”

Developers can add url to their own “descriptor file” containing all neccessary info about the plugin. Version, zip/tarball location, icon url etc

Developers can choose to host their own plugins on a regular webserver or wherever (or the central server if they want).

Almost like eclipse works with plugins…

So basically this would result in an alternative app store for the vera.

I reported quite a few bugs and feature requests for, never ever has mcv reacted to single one of them. This includes safety issues, update issues, paid plugin issues, licencing issues, version handling issues, description issues, uninstallation issues and so on. For this reason I would be very interessted in your approach!

I am also willing to contribute with knowledge and time as far as possible and I would also offer to be part of the beta team with all the plugins I published.

The new infrastructure should probably also allow dependencies.

I.e Combination Switch also installs Heliotrope version X.
We could also have shared libraries etc.

A la Maven style…

Yep my PLEG requires PLC

Maybe easier to plan this type of thing distribuated in a shared Google Document.

If anyone is interesten in participating, please PM your gmail-addresses and i’ll create and add you to a shared document…

Google: Richard.T.Schaefer
Let’s start a collaborative Requirements document.
We can then do a collaborative design document.
I am willing to commit resources … I continue to be frustrated by the existing App store.
If you start a boiler plate document … I will be glad to start adding content.

Ok, you have been added. I’ve created a shared folder if we need to store other types of documents aswell.

Anyone else wants to join … PM your gmailaddress…

Sounds like a great idea to me… you might want to look at how XBMC does it. They have the ability to add public and private repos and do everything else you are talking about.

As for Updates, my features I think are useful…

[ul][li]User option to turn off Auto Update, per plugin
Method to get a notification about updates (before and/or after they are installed) - email is ideal IMO.[/li]

Let’s not reinvent the wheel here. OpenWrt already has a package management system, handling dependencies, conflicts, versioning. To me it makes sense for us to use as much of that ecosystem as possible.

I agree with re-use.
However openwrt is oriented at unix command line users and developers.
I am not sure how much of it’s eco-system matches the requirements of an APP store interface for getting code from savy developers … to NOT so savy users.

Point taken. I’m just suggesting that whatever you develop, make it wrap calls to opkg install, opkg update and so on, to take advantage of all of the package-management work that OpenWrt has already done for you. The end user need not even know that it’s shelling out to opkg to do the work.

I’m not able to contribute any time to this endeavour, sorry, but I wish you the best of luck.

Creating opkg-package might be a too big threshold for some plugin developers?

But its quite powerful.

Our initial idea is a simple xml descriptor…It’s good to get all input we can get at this stage… If you later find some time to contribute, please let me know (send your email) to have a look at the gdoc.