Thanks to Tom for dumping the core variable arrays... lots to chose from there.

 

I would like to suggest an array "$plugins" with the same structure of the "$pages" array, containing the contents of the .page files from plugin root (e.g. /boot/config/plugins).

 

BTW, I like the fact that the $pages array does not use a predefined struc, but rather allows ad-hoc creation of additional array elements just by including them in the .page file.  That was very forward-thinking.

Why not expose these properties using simple 'webservices'. They can be implemented using php or any language Tom wants to use.

 

These webservices can be url's with querystring parameters (if needed) and return xml data.

 

So for instance just a http://localhost/unraid/get_array_info.php

 

<array>

  <disks>

    <disk id="1"><temperature>35</temperature></disk>

    <disk id="2"><temperature>28<temperature></disk>

  </disks>

  <status>Parity check</status>

</array>

 

 

followed by

 

http://localhost/unraid/get_disk_info.php?disk_id=2

 

<disk>

  <serial>308734897</serial>

  <state></state>

<disk>

 

or

 

http://localhost/unraid/disk_action.php?disk_id=1&action=spindown

 

Note: sample is not a proposal for the actual structure/fields

 

Now any plugin can simply use these services by calling the urls

 

 

This would also allow external tools to monitor the unRAID server. I'm just using the unraid server for a couple of days and have written a windows systray app which shows the unraid status just like the WHS icon (my previous storage solution). This tools uses telnet to get its information, but a webservice can be used by plugins and all other tools.

Why not expose these properties using simple 'webservices'.

 

Because you don't need to..... You can easily do that with a plugin.

 

Write your php code to return anything from the array parameters based on the http get parameters you call it with.

 

It would be quite simple.  Then you can poll any parameter of any device via a http get.

 

I will be doing something like that, to make all the data unraid_info reports to be accessible through a simple web call.

 

 

So you'll be doing that, and Joe L might be doing that, and I'll be doing that, and...

 

So why could that not be the primary interface. If anyone wants to write a new 'unmenu' using ruby on sinatra or whatever, they should not have to first write the interface layer using php.

 

My vote would be for a language independent api.

 

As a newbie on this forum, my vote counts far less than yours and Joe L's 

 

Your last sentence 'I will be doing something like that, to make all the data unraid_info reports to be accessible through a simple web call.' would be the perfect api, so why not support it natively from unRAID. This would be a great layer between the unRAID system and everything else with huge benefits to Tom (he can do anything with unRAID as long as he keeps the url's return the same xml or more) and the external tools will have stable api.

Would you rather Tom work on trivial stuff like that, or have Tom concentrate on core driver issues like 2nd parity drive, and let lesser mortals handle the grunt work?

 

Tom *has* provided a uniform API... it is fully documented in the php variables in the 5.0 interface under the Utils tab.

The basis of all communication from external software to the unRAID core is not trivial stuff in my opinion.

 

php variables are a uniform api, but not a language independant api.

 

As you've said yourself, exposing the variables using http/xml would be a very simple task, one which could even be done by someone other than Tom and sanctioned by Tom. I still think this would be a better basis for future work (work by others) and would alleviate Tom in the future.

 

 

The basis of all communication from external software to the unRAID core is not trivial stuff in my opinion.

 

php variables are a uniform api, but not a language independant api.

 

As you've said yourself, exposing the variables using http/xml would be a very simple task, one which could even be done by someone other than Tom and sanctioned by Tom. I still think this would be a better basis for future work (work by others) and would alleviate Tom in the future.

 

 

 

If someone gets something in place and is done up well enough We could just ask Tom to then include it in the distribution.

php variables are a uniform api, but not a language independent api.

 

But you access them via an http get... that is the epitome of language independent.

They are exposed as http get from unRAID to the plugin. The proposed mini-webservice exposes them from the plugin to unraid. But lets not get into a semantic discussion (as my used terms in the previous sentence are not 100% correct).

 

But I'll write a couple of php pages to get my personal management tool to talk to unraid, or I'll use yours

Currently, unRAID wraps the plugin output in the base html, so you can't do something clean like return a text header and just one line of plain text.

 

You will have to wrap the return values with something grep-able.

 

Or you can just retrieve http://tower/Utils/Vars and parse it.

Solution is in this post:

 

http://lime-technology.com/forum/index.php?topic=7082.0

Good work !

 

Hope Tom decides to make it a default function of the new release.