This page last changed on Apr 21, 2009 by juha.

Couple of key pages to follow what is happening with the Beehive project:

What Is Beehive?
Beehive Project Status
Beehive Roadmap

As our forum volume is still manageable (i.e. low), all Beehive discussions are welcome in this design forum.

UPDATE 2009/04/21:

Beehive has been deployed and is currently being tested (in Beta2 status) together with User Interface Composer Overview. Beehive data can be queried visually through the infrared remote selection in UI composer interface, see http://composer.openremote.org/demo. The current Beehive REST API (as it stands in Beta2) can be found here.

UPDATE 2009/02/15:

We've currently implemented the SQL schema for LIRC data, imported current LIRC data into MySQL database and have implemented Java, HTTP/REST and JSON APIs to access data in Beehive.

First iteration of the web user interface will be available shortly. We will proceed to deploy a beta instance of the Beehive database soon after.

Why not to use a document base and schema-free database like CoucheDB? With CoucheDB the HTTP/REST/JSON API would come out of the box for free. I think it may be more adapted for this project than SQL + Java frontend but maybe I don't have the whole picture.

Posted by rs at Apr 21, 2009 02:24

Hello Olivier,

The reason is very common – SQL is a well known and proven technology. It works for our use case. Therefore there seems very little advantage to learn a new system which won't help us move the real project forward which actually has very little to do with data or document management, and a lot to do with implementing HA protocols, etc.

The project itself looks interesting though. I'd be curious to know why the developers chose to do this and exactly what are the use cases they see provide benefits over a relational schema.

– Juha

Posted by juha at Apr 21, 2009 08:19

Actually my idea was more to use CoucheDb as a drop-in remplacement for all the beehive code. You would only have to code some quick data importers and all the rest would be handled by CoucheDb directly (RESTful interface to data, right management etc.).

Posted by rs at Apr 21, 2009 11:10

To answer to the second part of your answer, a lot of projects like this emerge those days, just because most web applications (and a lot of other projects) use relational databases where they just don't need it, with all the complexity and performance cost associated. The Beehive schema is a perfect example. At the end it will be data associated to devices like IR code, vendor name, capabilities etc, with different schema requirements for different types of devices. The regidity of SQL will impose you to concive a complexe normlized schema to handle all differents possibilities with associated code to be able to query it thru, at the very end, a RESTful API which only cares about devices (and other future entity stored in this db obviousely).

I know, it's a big design decision and it's always hard to trash code. But at this stage of the project, I don't think it's too late, and it will save you a lot of time to do things that really matter for the project.

Posted by rs at Apr 21, 2009 11:28

Hello Olivier,

I appreciate your enthusiasm for CouchDB and thanks for pointing out a new product I wasn't aware of. Hope you will stick around and share more ideas around home automation and OpenRemote.

You've made some good points even I don't agree with all your conclusions.

The actual REST implementation does not require coding on our part but is accomplished by annotating the Java object model using a JAX-RS API. The object model itself needs to be defined of course to act as a description of the data that is being transformed from REST representation to relational schema. The object to relational mapping is again automated by Java Persistence API so no code involved there either, but annotating object model and configuration (and database deployment).

So in that sense I am not worried about Beehive taking a huge part of the project implementation time, since both REST/JSON and object-relational mappings are automated.

The SQL performance is not a huge issue either as Beehive is used at configuration/install time, not at runtime.

The fact that there's a new query language to learn would have an impact to the project since everyone would have to learn it. Since we are pretty much done with Beehive (deployed and at Beta2) for our 1.0 release, no change is going to occur at this point.

Your point about disparate models for devices is well taken and agreed with. We will need to find a way to deal with it. Fortunately the relational model is well insulated from all clients behind a REST interface which should help us manage the evolution as we move forward.

Best regards,

– Juha

Posted by juha at Apr 21, 2009 14:27

Thanks for your kind answer Juha,

I understood you won't change your mind, so I won't insiste I just want to react on your point about new query language to learn. Actually, YOU are creating a new query language beeing your REST API. A query language finaly very close to CoucheDb query language, it's why I though about it in a first place. Thus your argument is fighting against you

Posted by rs at Apr 21, 2009 14:42

Hi Olivier,

Point taken, from the perspective of somebody integrating to Beehive, yes they would need to learn our REST API. Until now I had always considered REST APIs being rather domain specific, and hadn't heard of efforts to standardize REST or JSON APIs for specific tasks such as datastore integration.

My point, however, was from the perspective of developers implementing this project currently. And I think there the point still stands.

Best,

– Juha

Posted by juha at Apr 21, 2009 15:00

Juha,

I don't get it, developoers implementing this projects will have to interface with beehive, thus they'll have to learn its API as SQL here is totally abstracted by it. The only developers who will have to deal with well known SQL will be ones implementing Beehive, but that wouldn't happen with CoucheDb because it's already developped. Nice try though

Cheers,

Posted by rs at Apr 21, 2009 15:17

You seem to be looking for some trick in my argument. There isn't any.

Posted by juha at Apr 21, 2009 15:37
Document generated by Confluence on Jun 05, 2016 09:29