Since (hopefully) going forward plug-ins will be a big part of unraid, I think it would be a good idea to split the plug-in section off to a "release/support" and a "request/discussion" section, so things can stay more organized. And maybe the people who have created more plug-ins get together, similar to the thread about plug-in rules, and come up with some general guidelines, and sticky the thread so it doesn't get lost.

 

I think this will help greatly with keeping things organized as well as getting people started with plug-ins.

 

 

even better would be some way to install and look at a list of them all directly in unraid... ;-)  some sort of SimpleFeatures add on would be awesome..

 

 

even better would be some way to install and look at a list of them all directly in unraid... ;-)  some sort of SimpleFeatures add on would be awesome..

 

Yeah a repository similar to the unmenu packages would be really great. We would need some place to host the files though, that all the developers can access, instead of it being managed by one person so plugins are always up to date.

It could be managed on sourceforge/github/google code. As someone wants to release a plug-in, simply tell another plug-in dev who can add you to the list.

 

Since the plug-ins are a large part(atleast, large beta part) of unraid, it'd be awesome if limetech could host it. The repository wouldn't use much traffic at all, these plugins are only a few kb apiece.

even better would be some way to install and look at a list of them all directly in unraid... ;-)  some sort of SimpleFeatures add on would be awesome..

 

I'm actually working on an idea for a repository right now, not sure if anything will come of it but we'll see.

For a repository to work correctly, and be easy for dev's as well, there would have to be some uniform way to name plug-ins. It works quite well with the version in the name, making it easier to check for a newer version, but there are too many variables right now to be able to accurately pull the version from the name.

 

Right now, to name a few plug-ins, this is what we have:

 

sabnzbd-0.4c-i468-bw.plg

couchpotato-0.5-i468.plg

logmein-hamachi-1.0.2-noarch.plg

headphones-0.1b-influenced.plg

logitechmediaserver-7.7.2-plugin_V1.3.plg

 

The naming scheme is largely the same, but with key differences:

1) Hyphens are used in different places, they are most commonly used to separate the version number, but also used in the app name, such as logmein-hamachi.

2)Logitechmediaserver has both the app version and the plugin version number, with the plugin version denoted by the "V". This wouldn't apply to most plug-ins as the app version is independent of plugin.

3)Benni-Chan's plugins have i486 in the names, while not a problem normally, unless a scheme can be made with the version easily extracted, by way of delimiter or simply being the only numbers, it could pose an issue.

 

I've tested different ways to get the version number from the file name at the repository, the simplest method would be using preg_replace to strip all but numbers and periods. Another way I've tested was using explode() and delimiting by the hyphen, which works just as well, but in the case of logmein-hamachi the version would be shown as "hamachi" instead of "1.0.2". Neither method would accurately work with logitechmediaserver, as the actual plug-in version is not the number between the hyphens.

 

I propose we have the naming convention as follows:

 

appname-version-author.plg

 

The appname would have no hyphens, underscores or other characters would be acceptable, but hyphens should only be used to separate version # from appname and author.

 

Author would not necessarily have to be in the app, but it seems it is in most, and proves to be a good way to differentiate between different plug-ins for the same app. For this reason I propose it is used.

 

The version could contain letters, but it would probably be cleaner to leave them out altogether. The code I have tested works fine with or without numbers so this is not an issue. Instead of using letters, version numbers should be formatted as 0.0.0, which we all understand I believe. Full stable version - Major revision - minor revision(atleast this is how I always read it). For instance, with my headphones plugin(which does not currently follow this format), it is version 0.1b, with the version format proposed, it would be version 0.1.2, meaning I have not released it as 100% stable, it is the first major revision and second minor revision. Minor revision being I cleaned up some code and stripped some unneeded dependencies.

 

What do all of those active in plug-in development think of this? Going forward with the ability to use plug-ins, it would seem to be a good opportunity to have a standardized format from the (near) beginning, making things simpler going forward.

I'm considering dabling in plug-ins myself and am wondering if anyone has, or could, come up with an "anatomy of a plug" in primer?  I'm not looking for anyone to teach my linux or php or .js or anything.  I just want to understand how plug-ins are called to install, what are required elements of a plug-in for unraid to process it, are their any idiocynracies that would not be obvious to me as I try to reverse engineer something "simple" like maybe the screen plug-in.  Simple in this case because it doesn't do anything more than install screen and doesn't muck about with the GUI.

Plugins are fairly simple.can be fairly simple, or as complicated as you desire to make them. Basically, the plugin holds all the information needed. This can include created php pages, scripts, or anything else you might need/want in your plugin.

 

Screen is an extremely simple plug-in. The <FILE> tag tells installplg(the app that auto installs plugins in the /boot/config/plugins directory) to create that file, the name attribute lets unraid know where to put the file. The Run attribute is a command that runs once it is created. The <URL> tag tells the parser to download the file in the url and save it as the <FILE> name.

 

The <MD5> line is where you can put the MD5sum for the file being downloaded, unraid will run a md5 check when this is present to ensure the file downloaded correctly and is genuine.

 

The <INLINE> tag is to let anything you write inside the tag be written exactly how it is typed, so spaces, new lines, and tabs are kept in place, which is important if you are writing another coded file(like a php page) with the plugin.

 

<INLINE> is accompanied by <![CDATA[ which closes with ]]>, this lets the xml parser know that anything inside of <![CDATA[ is character data, and is not to be executed or parsed like regular xml.

The plugin must have the extension .plg, and must be in xml format with the <PLUGIN> tag at the top to let unraid know it is a plugin to be installed.

 

Thats just a quick explanation of the barebones features, if you need any more assistance just ask!

That is a great and confirms what I guessed from checking out the openssh plugin (was easier to view that here at work where I can't read tgz files

 

So what I gleaned from openssh, and from looking at my flash drive last night after an install took place, is that the plugin still creates files inside /boot/packages ... at least the openssh one does.

 

Is that how most of these go?  In so much as all the plug-in is realy doing is automating pushing a file into packages to then be installed at boot?

 

Which I assume is what packages pulled via JoeL's unmenu package manager are doing?

 

And how / what is speeding_ant doing then with simplefeatures in the /boot/extra folder and .tgz files?  I mean from my perspective he is just creating a random folder and unraid is automagically doing stuff with it

boot/extra contains compressed archives that are automatically installed on boot. From what I can tell, these must hold the directories/files needed. For instance, with simple features, speeding_ant installs files to the /usr/ directory, so inside his archive is the /usr/ path, I suspect these get copied directly over the files that come with unraid. That make sense? Its like if you have a C:\Pictures folder and wanted to add pictures to it, and overwrite a few, you could copy another folder named Pictures to C:\ and it would add to and overwrite C:\Pictures.

 

boot/packages is simply a folder to keep all the packages you use on unraid. From Joe L's package manage, if you choose to auto install on boot, a auto install.conf is made and a line is added to the go script to install these automatically. Plug-ins do the same thing, in a different manner. The plug-ins are installed on boot, so the <FILE> line points to the file, if its not there it downloads the file, and installs it.

 

Plug-ins can do any number of things, from installing packages, making php pages, to running scripts. If you can code it, the plug-in can do it.

 

Other plug-ins, like couchpotato or sabnzbd, download and install the program, and allow you to set where to install it and where to keep the data directory, what port to run on, and what user to run as. This is done by creating a PHP page to show within the unraid webgui. All of this is done through the plug-in. Check one of those out. I haven't looked at the openssh plug-in but it sounds like one of the others I named are more robust. But they too are barely scratching the surface of what could be done with a plug-in!

ahhh ok that seems to make sense.  I tried decoding one of the smaller simplefeatures tgz files and was a bit lost at sea.  it might make more sense now with that context in mind.  i'll have a look when I get home.

 

Yeah openssh is a very simple plugin but for initial learning purposes it was nice because it does just a little bit of INLINE work to accomlpish some conditional tests and generates key files as well as some chmod lines.  So now I see the the concept of how things are done.  PHP will surely be my limting factor as I've seen it but never hacked on it before.  A perfect excuse to start learning

 

Thanks.

The "Slimserver" plugin written by Limetech has lots of explanations about the creation of plugins, including a naming convention, a folder architecture and the usage of the different sections inside a plugin, see here.

 

Study the "mother" of the plugins and stick to the conventions layed out in there. That should bring some uniformity to the plugin story.

 

I was wondering if it might be a good idea to host all files needed by a plugin at google code, or github?  The only reason I bring this up is because I just had to modify the istatd plugin because one of the required files was linked to a "current" subdirectory, rather than linking to a file in a static directory.  Because the "current" release changed, and the file was updated, a new version of the file resides in the linked directory, with a different version number, causing the plugin installation to fail.  I fixed it by pointing to a new version of the file, but it's still grabbing said file from a "current" directory, and I can't seem to find a working version of the file hosted outside a "current" directory, meaning it will eventually break again.

 

Even assuming that you could grab the latest file, regardless of the version number, it's still possible that it could break the plugin installation (compatibility problems, deprecated functions, etc).

 

I'd much rather see a plugin fail spectacularly because none of the files it requires are available, than see a plugin fail because 1 of the several files required can't be downloaded, and then have to track down why, and subsequently find a version of that file that works with the plugin.

 

 

 

 

I think that this is a truly fantastic idea! One which I hope will be officially supported (the plugin system not the actual plugins). The benefits are huge!

 

Has anyone had any feedback on how Tom\LimeTech feels about this, is it in any kind of roadmap already? I see it being a simplefeatures thing above the standard 5 releases though?

Can we set up a common github, where we all store all the packages ?

 

//Peter

Can we set up a common github, where we all store all the packages ?

 

//Peter

 

I don't know enough about github or google code to know whether either would work as a common repository for files necessary for all plugins.  The concern would likely be only a handful of people should have write access etc.  It could easily be come a management nightmare.

 

I'm thinking of common "best practices" for plugin creation, one of them being that all files required for the plugin to function exist in either google code, or github, or some other, robust, accessible place that isn't going to disappear overnight.

 

Beyond that we could have a central repo that a few people maintain, and after obtaining permission from the plugin creator, the plugin can be modified to point to the central repo for all files necessary for the plugin to work.  Maintainers would solely be responsible for trying to ensure the files necessary for the plugin to function are available for download.  This way some of the more popular plugins can be ensured to work on older versions of unRAID, even in the face of updates to unRAID and the plugin.

 

Consider the following scenario:

 

You setup unRAID for a friend who isn't technically savvy, they move thousands of [kilometers/miles] away.  But unRAID just works.  For 2 years.  Suddenly after a power failure the array comes up, but none of their plugins work because the required files are no longer available for download.  You had configured a way to offer support , but since moving their router has changed, and now you have to try and walk them through port forwarding, or telnetting in and running commands, or some other complicated thing to get them back up and running.

 

That doesn't sound like fun to me.

Two words, team viewer. There is a definite need here for a.central repo, but I think it would be a waste to implement before seeing what limetech does

There is a definite need here for a.central repo, but I think it would be a waste to implement before seeing what limetech does

I agree 1000%.

 

The repository needs to be centralized, and managed by more than just Tom @ lime-tech, but he has to be involved in its creation/design.  Perhaps he'll be open to hosting the needed packages.  If not, the package manager needs to be able to deal with alternate repositories, in alternate hosted locations, much like Ubuntu with official repositories, vs alternate/development ones, or XBMC with its add-ons and the "Official Add-ons' vs. those contributed by others or those still in development.

 

Joe L.