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.
So basically this would result in an alternative app store for the vera.
I reported quite a few bugs and feature requests for apps.mios.com, 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.
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.
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]
[li][/li][/ul]
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.
Best Home Automation shopping experience. Shop at Ezlo!
