rutherford Posted December 2, 2011 Posted December 2, 2011 I was thinking about unRaid last night and I think the major shortcoming of the software that I've seen thus far is the variety of plugins. Not the number of them, but the way in which they're implemented. unMenu, plg, and brute installs to name a few. I think the next thing for Tom to work on is a plugin standard that works for all developers. It should be pretty, functional, persistent over reboots, configurable from the regular limetech sub-menus, independent (not causing the system to hang when it screws up), updateable with the latest versions of the softwares. Specifically the programs I have in mind are: sabnzbd, couchpotato, sickbeard, and transmission.
prostuff1 Posted December 2, 2011 Posted December 2, 2011 I was thinking about unRaid last night and I think the major shortcoming of the software that I've seen thus far is the variety of plugins. Not the number of them, but the way in which they're implemented. unMenu, plg, and brute installs to name a few. I think the next thing for Tom to work on is a plugin standard that works for all developers. It should be pretty, functional, persistent over reboots, configurable from the regular limetech sub-menus, independent (not causing the system to hang when it screws up), updateable with the latest versions of the softwares. Specifically the programs I have in mind are: sabnzbd, couchpotato, sickbeard, and transmission. That is what the .plg system it for. It is very new and very still in development/refinement. unMenu has existed for a long long time and the reason most extra apps exist as installs through that is because it has been around and because it is fairly easy to develope towards. There is not a lot of documentation for creating the packages but there are packages in there that are quite large and show just what can be done.
abs0lut.zer0 Posted December 2, 2011 Posted December 2, 2011 I was thinking about unRaid last night and I think the major shortcoming of the software that I've seen thus far is the variety of plugins. Not the number of them, but the way in which they're implemented. unMenu, plg, and brute installs to name a few. I think the next thing for Tom to work on is a plugin standard that works for all developers. It should be pretty, functional, persistent over reboots, configurable from the regular limetech sub-menus, independent (not causing the system to hang when it screws up), updateable with the latest versions of the softwares. Specifically the programs I have in mind are: sabnzbd, couchpotato, sickbeard, and transmission. As an absolute scripting noob (and not really much of a desire to learn) i very much agree with this statement, this software is fantastic (unRAID) and what the user community brings to it is absolute brilliance but how to make the scripts, plugins and customizations work is sometimes scary to the point of wow that is great but i don't wanna break my already working stable unRAID so lets just watch people that are willing to take the plunge and enjoy the benefits.
Joe L. Posted December 2, 2011 Posted December 2, 2011 I was thinking about unRaid last night and I think the major shortcoming of the software that I've seen thus far is the variety of plugins. Not the number of them, but the way in which they're implemented. unMenu, plg, and brute installs to name a few. I think the next thing for Tom to work on is a plugin standard that works for all developers. It should be pretty, functional, persistent over reboots, configurable from the regular limetech sub-menus, independent (not causing the system to hang when it screws up), updateable with the latest versions of the softwares. Specifically the programs I have in mind are: sabnzbd, couchpotato, sickbeard, and transmission. That is what the .plg system it for. It is very new and very still in development/refinement. Tom @ lime-tech has stated exactly that. His goal is to have a package manager built into unRAID. Before he can "manage" them, he decided to first learn from what was developed in unMENU's scheme of defining installable packages, improve on it, and get the ability to install packages working. That is what you are seeing in the .plg files. The beginning of the ability to install packages in unRAID. Tom has also stated he is also developing the "event" handling aspect for those packages, but for now, he is depending on us, the user-community to help in handling those pre-shutdown and post-startup events. For now, unRAID will wait forever for the plugins to complete before continuing. In other words, today, a single mis-behaving plug-in can freeze the whole process of either starting up, or shutting down. There is at least one long thread discussing that topic. Since the event handling is in its infancy, very few add-ons are using it. I've used my own scripts to handle those events, but they rely upon polling the system log to determine when to start and stop tasks. unMenu has existed for a long long time and the reason most extra apps exist as installs through that is because it has been around and because it is fairly easy to develope towards. True... prior to it, all extras were added by hand, by lines added to the config/go script There is not a lot of documentation for creating the packages but there are packages in there that are quite large and show just what can be done. Actually, there is... in the wiki here: http://lime-technology.com/wiki/index.php?title=UnMENU_documentation#Package_Manager Tom initially tried an "extra" folder, and it still exists for installation of some simple packages that require no local variables or configuration. Until there exists a package manager similar to the one in unMENU, you'll see all of these in use. The .plg format is only slightly more complicated than the .conf format I used in unMENU. (It, in fact, is basically an XML implementation of what unMENU uses) In the mean time, if you are not talented at scripting, wait for feedback on any package made available by others. (don't be the first to install it) Although most packages are not able to harm your data, there is always the possibility of some unforseen interaction with other script, or with something on your server configured differently. Lastly, before doing ANYTHING to the add-on manager, a much higher priority is to get the 5.0 series out of beta, and to fix the 2 bugs in the 4.7-final version that could potentially cause loss of data. Joe L.
rutherford Posted December 4, 2011 Author Posted December 4, 2011 This may be ridiculous... But rather than writing the entire unRaid web GUI, why not use someone else's GUI - like x-windows X11 http://www.xfree86.org/ Users could get the client on whatever box they're running on, and connect to the unRaid server that way. That might solve a bunch of problems. Prolly create a few too, but in the long run, it might make things easier. Developing stuff for x-windows rather than the proprietary web gui.
WeeboTech Posted December 4, 2011 Posted December 4, 2011 This may be ridiculous... But rather than writing the entire unRaid web GUI, why not use someone else's GUI - like x-windows X11 http://www.xfree86.org/ Users could get the client on whatever box they're running on, and connect to the unRaid server that way. That might solve a bunch of problems. Prolly create a few too, but in the long run, it might make things easier. Developing stuff for x-windows rather than the proprietary web gui. I think more people are familiar with html/php and scripting rather then programming in C/C++ and/or X11. With recent additions to emhttp and PHP allot of opportunity is there to make webGui plugins. I only wish there were a standard CGI interface so I could use perl and other tools easier. In all, I like the current direction unRAID is going with api access.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.