Word the poll carefully cause most users with experience will be just that ... users. The admin/dev part of it is probably more important and we don't want that compromised by a flood user with no backend experience votes

Yeah, yeah gimmee something to click on yeah, yeah..........

 

Personally I think whomever wants to compile a list of options with maybe some good sound reasons for each option and then present it to either limetech or the plugin guys for decisions. I mean you could come up with a great poll then find out like mentioned people will vote for things that they don't even know what they are.

 

I'm not a strong dev, but I've done my share of coding in various languages over the years, but have I really done anything that involves many devs at the same time? Nope so I wouldn't be the best person to even click a box in a poll nor do I think I should sway any influence towards a final decision..

Maybe it is better to hold a poll for the more experienced people. For instance the Hero members...

Great suggestions!  Personally I'm leaning toward google code, since hopefully there will be numerous plugins & customized webGui's.

 

So here's a status update....  release 5.0 is just about ready.  I'm in the process of converting all the 'built-in' webGui pages to PHP and it's tedious as hell.  I'm about 75% through & when finished I'll be able to post 5.0-beta1.

 

Yes, PHP.  Attached are some screenshots.

I really like the settings page myself with the icons/images.

 

The rest looks nice too, but I really like it. I have other suggestions, but honestly I don't want to keep you working on web stuff when you have other important stuff you could be doing.

Yes the goal is to first complete the existing webGui functionality in the new design & then set others loose on refinements while I tackle additional features.

Looking good thanks for the preview.

 

Php = awesome choice.

 

Can you look at the spacing location of refresh and stop buttons. Putting the button that is pressed the most "refresh" beside the button that is pressed the least "stop" has always seemed like a risk to me.

 

Or add an "are you sure" to stop.

 

Early days perhaps for suggestions of that level.

 

Also can you consider branding when you are adding logos etc. It should be easy enough to re-brand unRAID for resales whilst always keeping clear indication that it is a Limetech product.

 

Nice one.

 

As for google code there is no reason we cant start there at least although i think users will quickly tire of there being potentially dozens of seperate google code projects. Food for thought.

This could entirely be done right now if there was a consensus.

I don't know if a consensus is the only thing needed. This all takes time and money. Limetech seems quite busy.

 

Would cost absolutely nothing (other than time) for the core plugin developers (there are an obvious few who spring to mind) to create a google code project (or similar) and put all their plugins under it in one place. And we go from there.

 

Having it alongside whatever unraid may choose to do in the future would be great but as you say there are significant barriers to that. Doing the above would still be a huge step forward for plugins in my opinion. But then that comes as predominantly a user rather than the maintainer of plugins.

This could entirely be done right now if there was a consensus.

I don't know if a consensus is the only thing needed. This all takes time and money. Limetech seems quite busy.

 

Would cost absolutely nothing (other than time) for the core plugin developers (there are an obvious few who spring to mind) to create a google code project (or similar) and put all their plugins under it in one place. And we go from there.

 

Having it alongside whatever unraid may choose to do in the future would be great but as you say there are significant barriers to that. Doing the above would still be a huge step forward for plugins in my opinion. But then that comes as predominantly a user rather than the maintainer of plugins.

 

I suppose if you build it they will follow, Yet it's already built. How many plugins are there.

We can use the wiki as a jump page or another google code page as a jump page.

Frankly the wiki is a better thought in my mind.

 

I do not think collecting all the plugins into one google code page would work.

Each developer needs svn access.  So someone needs to maintain the master account and grant access to store and change.

 

NAS had a good idea for the jump page or Table of contents and it was a good start, but no one moved forward in that direction.

 

What if we used what we have today until something better comes along.

The Wiki, Individual Developer google code projects.

The key is to use the unRAID keyword for searches.

A Quick search brought up.

 

http://code.google.com/p/unraid-unmenu/

http://code.google.com/p/unraid-powercontrol/

http://code.google.com/p/untorrent/

http://code.google.com/p/unmenu-bsm/

http://code.google.com/p/gfjardim/

 

For me I have two google code projects.

 

One for power down.

One for generic scripts.

http://code.google.com/p/unraid-weebotech/

 

As I started to update powerdown this weekend, I realized, I could not remember all the requests for changes.  Yet the tool to log the issues and requests is right there.

I think people just need to be motivated to go there.

 

I think the forum itself needs some strategic links to the wiki to help.

As for google code there is no reason we cant start there at least although i think users will quickly tire of there being potentially dozens of seperate google code projects. Food for thought.

 

Start the jump page/Table of Plugins in the Wiki.

Can you look at the spacing location of refresh and stop buttons. Putting the button that is pressed the most "refresh" beside the button that is pressed the least "stop" has always seemed like a risk to me.

 

Or add an "are you sure" to stop.

 

Early days perhaps for suggestions of that level.

 

Also can you consider branding when you are adding logos etc. It should be easy enough to re-brand unRAID for resales whilst always keeping clear indication that it is a Limetech product.

 

Probably best to hold these in a document for posting after the Beta is released.

In some sense if I were developing, I would want this to be collected and put in one area.

Might be hard to take these on in drips and drabs. Once limetech has their own googlecode page, It should be easier.

So here's a status update....  release 5.0 is just about ready.  I'm in the process of converting all the 'built-in' webGui pages to PHP and it's tedious as hell.  I'm about 75% through & when finished I'll be able to post 5.0-beta1.

 

This goes a long way. Thanks for the update.

Why PHP, I thought you were going to do something in Sinatra? (I'm not complaining. I think PHP is a wise choice).

I suppose if you build it they will follow, Yet it's already built. How many plugins are there.

 

Quite a lot?

 

And presuming we get anything like the framework promised in unraid 5 many many more to follow.

 

Frankly the wiki is a better thought in my mind.

 

The wiki needs kept up to date. I'm not slating the hard work of anyone here but it's currently not. At best the wiki points to a forum thread which is dozen of pages long with updates to the download and instructions scattered throughout it.

 

Each developer needs svn access.  So someone needs to maintain the master account and grant access to store and change.

 

Hence a consensus required! For a 'communal' account no reason why a few of the big hitters couldn't share the master account. And then the rest is just permissions on a per plugin basis.

 

NAS had a good idea for the jump page or Table of contents and it was a good start, but no one moved forward in that direction.

 

Because it requires maintenance. A google code or similar would 'maintain itself' by way of updates to the plugins going there by default.

 

http://code.google.com/p/unraid-unmenu/

http://code.google.com/p/unraid-powercontrol/

http://code.google.com/p/untorrent/

http://code.google.com/p/unmenu-bsm/

http://code.google.com/p/gfjardim/

 

So now I'm searching the wiki and having to search google code. And this presume all unraid plugins are on google code and not something else / tucked on the devs website elsewhere.

 

I think the forum itself needs some strategic links to the wiki to help.

 

We need a single port of call for plugins. Whether that's a webpage with a list of (up to date) links in whatever format you want (static html or part of the wiki here) or all plugins being hosted under a single google code or similar page is largely immaterial.

 

But we have the former now with the wiki and I don't find it that useful as it's just a starting point to a long wade through many forum posts. A single, static web url as the master repository for the up to date download and current docs would be much better - from a user point of view. And would also allow better maintenance and tracking from a developer point of view if using google code or similar.

 

Ultimately the best way would be for us to have our own package management repository and then the backend can be largely transparent. bubbaq touched on this earlier as I believe this is exactly what the NMT folks have done. I don't know much about distributed package management under slackware but an obvious analogy would be an unraid-plugin yum repostory under RHEL  or apt source under debian.

 

Unmenu sort of does this already but it's not foolproof (and I imagine was not meant to be) given urls to packages swiftly go out of date etc.

 

Everything at the moment third party to unraid is 'scattered around' held together loosely by the wiki and the forum. There's no reason the wiki entry can't be a simple one line :

 

'Find 3rd party unraid plugins here : google.code/unraidplugins'

 

And everytime a plugin is release / updated / referenced in the forum :

 

'updated on the unraidplugin site'.

 

Given I've never done a plugin and have only contributed a basic rtorrent / libtorrent package (which has since been superseded by the far far superior untorrent package) and cheap instructions on getting crashplan installed and running I'm really in no position to comment or drive this forward. But as a heavy plugin user this is what I'd like to see.

 

Edited to add if all this sat alongside unraid all the better. But it could just as easily be heavily reference / made 'official' by limtech via reference. To follow the trac analogy see the relationship between trac and trac-hacks - http://trac-hacks.org/

Can you look at the spacing location of refresh and stop buttons. Putting the button that is pressed the most "refresh" beside the button that is pressed the least "stop" has always seemed like a risk to me.

Very true...  I know I pressed it at least twice in error. 

 

suggestions for later... Put everything but the "refresh" at the bottom, or better yet, on their own "tab" for array maintenance, that way, the main page is just for array status..  The "Stop" button needs an "Are You Sure" prompt, even if only done in Javascript at the browser.

Yes, PHP. 

 

Exxxxxxcellent choice (said in the voice of Mr. Smithers while wringing hands maniacally)

 

And presuming we get anything like the framework promised in unraid 5 many many more to follow.

 

Since the GIU pages are in php, they are making calls to exposed APIs and that's all the framework you need to write plugins.

Can you look at the spacing location of refresh and stop buttons. Putting the button that is pressed the most "refresh" beside the button that is pressed the least "stop" has always seemed like a risk to me.

Very true...  I know I pressed it at least twice in error. 

 

suggestions for later... Put everything but the "refresh" at the bottom, or better yet, on their own "tab" for array maintenance, that way, the main page is just for array status..  The "Stop" button needs an "Are You Sure" prompt, even if only done in Javascript at the browser.

 

I dunno guys, this is all good and I agree with some of it, but at the current time, perhaps just basics of doing what is currently presented is better.

 

People are familiar with the current interface. if it starts to get changed too much, then we delay it's release and then there is the ongoing support of "where is this function".

 

As far as the first page being status.

Every nas I've used has been like that. Then you dig deeper to stop/start/configure/health.

But the first page is overall status and health.

 

Since it's 75% there and the interface looks familiar, do we want to institute changes now or let it go into beta and "assist" in the future changes.

 

I mention this because, we still need a central place for bugs/feature requests and that's what allot of this conversation has been about. (and maybe should be forked).

 

Ideally we could go with what limetech releases, limetech could setup the google code page and then we can have at with bug fixes/features and see how the process goes.

 

It's a new modality of how this community has functioned so there will be some "getting used to" and growing pains.  I'm all for the getting 5.0 out if it's going to be more administrator/developer extensible.

Boof you bring up allot of points.

Many of them come down to the same basic issue.  People maintaining continually.

Perhaps some "roles" and "masters' or "heroes" but it still is a responsibility.

 

My most recent idea of the "collective library of plugins" is a place where a configuration file contains the plugin and location.  This could be maintained on google code. Downloaded via some app and used as a jumping control file to gather what is needed. (google code or developer site).

 

My thought is, if the Wiki is not as complete as people want, it still boils down that someone has to do the work.

 

I'll have to take a look at the NMT community more to get a better idea. Right now I'm still in the same thought pattern as Joe L.

 

People are familiar with the current interface. if it starts to get changed too much, then we delay it's release and then there is the ongoing support of "where is this function".

 

Ditto.  Tom should not need to waste his time on UI stuff.  Just convert the existing interface to PHP and cut it loose.  Others can then carry that torch, and let Tom work on the core.

 

Eventually, Tom can put the php stock UI code into a google code variant, and the community can make suggestions to the stock UI (Tom would obviously be the only one with commit authority).

And what about kernel modules, guys? Here every time unRAID upgrades, I've to recompile kernel to enable these modules:

 

"tun/tap" and "802.1d Ethernet Bridging" for OpenVPN support (OpenVPN Addon would be very nice, since many servers out there are on 24/7);

 

"ACPI Processor P-States driver" and  "AMD Opteron/Athlon64 PowerNow!" for PowerNow! support;

gfjardim, surely you don't mean every time unRAID upgrades. Only when it upgrades the 'md' driver or the main kernel should it be needed. As long as it doesn't effect the kernel, you shouldn't have to recompile your modules, just because of an emhttp/shfs or other non-kernel items.

Kernel changes and additional modules are a different kettle of fish.  Adding them to stock makes stock bigger, and bumps up against the minimum HW requirements of a 512M flash.  Tom has to be somewhat selective about such things, even more so with unRAID 5 since obviously a lot of stuff is being added to the initramfs.

 

Rather than change the minimum HW to a 1GB flash, perhaps there could be a fuse-type overlay file system, so that a second flash (or cache drive) could be used for additional storage for upgradable portions of the root filesystem.

 

 

"ACPI Processor P-States driver" and  "AMD Opteron/Athlon64 PowerNow!" for PowerNow! support;

 

+1

Kernel changes and additional modules are a different kettle of fish.  Adding them to stock makes stock bigger, and bumps up against the minimum HW requirements of a 512M flash.  Tom has to be somewhat selective about such things, even more so with unRAID 5 since obviously a lot of stuff is being added to the initramfs.

 

Rather than change the minimum HW to a 1GB flash, perhaps there could be a fuse-type overlay file system, so that a second flash (or cache drive) could be used for additional storage for upgradable portions of the root filesystem.

 

I tried this with unionfs (worked, not stable enough) aufs (worked also)

 

In order to do this overlay with / ,  and a second flash, initramfs needs to be tmpfs.

I dunno if it can be done with FUSE, but I'm open to other technical knowledge.

 

>> "tun/tap" and "802.1d Ethernet Bridging" for OpenVPN support (OpenVPN Addon would be very nice, since many servers out there are on 24/7);

 

Part of me has the feeling that this level of networking doesn't belong on the core unRAID.

Yet, in contrast, Thecus has this on their units with built in switches.

 

The AMD power option is probably a good thing to add, Seems there are allot of AMD users on the forum.

 

What I do feel strongly about is CDROM usage. it's a storage server, and unRAID should have this as a readable storage option.  Frankly, I want to burn ISO's I have stored on unRAID with cdrecord too. Especially when i download a new linux dist or boot/repair cd.

 

I've often thought that all these drivers/modules should at least be compiled in.

The bare essentials included in the bzroot with an addon package that could install additional driver modules that a user needs. Sure would go a long way to handling these requests.

 

However, This should in no way delay 5.0. I think all these request and adding them here seem to dilute the 5.0 effort.

Great suggestions!  Personally I'm leaning toward google code, since hopefully there will be numerous plugins & customized webGui's.

 

So here's a status update....  release 5.0 is just about ready.  I'm in the process of converting all the 'built-in' webGui pages to PHP and it's tedious as hell.  I'm about 75% through & when finished I'll be able to post 5.0-beta1.

 

Yes, PHP.  Attached are some screenshots.

 

Thanks Limetech for the screenshots! The UI looks more professional. I like the settings page with the icons. I think a Lot of people want eye candy.  

 

Ditto.  Tom should not need to waste his time on UI stuff.  Just convert the existing interface to PHP and cut it loose.  Others can then carry that torch, and let Tom work on the core.

 

I think this also a good idea. Leave Limetech work on the core, and others work on the UI. Maybe the UI developers can take look at the Synology, Qnap interface how they build there web UI.

 

A Quick search brought up.

...

http://code.google.com/p/untorrent/

That's not mine. 

Somebody (Username: hiltner.11) posted it there under his own Google Code account.

I have no access rights to that page.