Is it possible to expose the configuration files to REST API?

[Mihail Panayotov]

Is it possible to expose the configuration files to the REST API in a
nice and easy way? I know it is planned to add read/write files
functionality in the REST API. However what I ask about is a
specialized services for the following tasks:
- read/write config parameters (in openhab.cfg)
- read/write items entries (not the whole *.items file)
- read/write rules entries (not the whole *.drl file)
- read/write sitemap entries (not the whole *.sitemap file)
- read/write transformation entries
- upload/delete sound and image files

These services will open openHAB to new configuration tools, for
example a web-based administration, which I would like to develop.

What do you think about this?

[Kai Kreuzer]

This sounds to me like misusing the REST API a bit.

As has been discussed earlier, I see the openHAB "openness" on a different level - the Java APIs / OSGi services are designed in a way that other implementations can provide item and sitemap definitions - the *.items and *.sitemap file are just ONE possible way to configure openHAB (and this is vial LOCAL files in the file system).

What you are asking for is rather access to the file system via HTTP. For such a use case, WebDAV is IMHO the preferred solution. It should actually be possible to configure Jetty to give WebDAV access to the openHAB config files. Would that work for you?

> --
> You received this message because you are subscribed to the Google Groups "openhab" group.
> To post to this group, send email to ope...@googlegroups.com.
> To unsubscribe from this group, send email to openhab+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/openhab?hl=en.
>

[Mihail Panayotov]

> the Java APIs / OSGi services are designed in a way that other implementations can provide item and sitemap definitions - the *.items and *.sitemap file are just ONE possible way to configure openHAB (and this is vial LOCAL files in the file system).

Yes, I know that. However for now the *.items and *.sitemap files are
the ONLY configuration storage for openHAB. I think there would be
some kind of database storage instead. And then openHAB could just
import config settings from *.items and *.sitemap files and other
different providers, for example XML files generated by other tools.
Or provide REST API to interact with item entries, rules entries,
sitemap entries and every other possible item that is configurable.
This way there would be standardized "gateway" for openHAB
configuration that could be checked for valid data and make some
normalization if needed. This gateway could be used by openHAB
Designer and other 3rd party tools.

This is not just access to the file system via HTTP. Its rather a
bundle of services for openHAB configuration in a nice, secure and
standardized way that would lead to different configuration tools.
Personally I would like to develop ExtJS based config tool for easy,
beautiful, geekless and out of the box configuration. :-)

[Kai]

My point is that I do not want to expose the item and sitemap file syntax itself, but only the underlying models; internally, these are currently EMF models and thus could be serialized in any document format (JSON, XML, etc.), which would be much easier to process by other configuration tools and which would also fit much nicer into the REST world. It would also mean that you could do a simple HTTP POST to create a single new item instead of having to define a complete "file".
But such an extension of the current REST API is not quick and easy. Hence it will need some thoughts and time to be implemented and it is not one of my top priorities at the moment - sorry about that...

[Mihail Panayotov]

> My point is that I do not want to expose the item and sitemap file syntax itself, but only the underlying models;

I know that, we have talked about this before. And I totally agree
with you. My point was to develop easy REST interface/gateway to these
underlying models, not just to give file access to config files.

> It would also mean that you could do a simple HTTP POST to create a single new item instead of having to define a complete "file".

This is exactly what I ask about :-)

> But such an extension of the current REST API is not quick and easy. Hence it will need some thoughts and time to be implemented and it is not one of my top priorities at the moment - sorry about that...

I understand this, there are currently more important issues. I just
wanted to ask if it's possible this kind of scenario.

[Kai]

Ok, then I am happy that we have a similar understanding.

I guess we can introduce these features subsequently; possibly starting with REST support for item management and later extending it to sitemaps, rules, and other resources.

[Mihail Panayotov]

I would be very happy with that. However a full working configuration
tool would be not possible until a full config API. But it's a good
start :)