[OpenTRV-dev] Clumpers or Splitters?

Damon Hart-Davis damon at opentrv.uk
Fri Aug 21 18:38:13 BST 2015


I am contemplating embarking on a thorough reorganisation of the OpenTRV code for a number of reasons:

  * Good engineering / testability.
  * Separation of concerns.
  * Making it easier for others to use individual parts of our (permissively-licensed) code such as our tiny OneWire driver.
  * Supporting the plug-n-play and modularity aspirations of the IoT Launchpad project.

In the past I have managed library stacks which have worked very well and been used by lots of groups and gone from a single library to 10s of libraries, but which because complex to manage and use, eg knowing "which underlying library version numbers do I need to go with this other library I have here"?  Java has tools such as Maven and Ivy to help with this, but at least 1.0.5 Arduino IDE land does not.  (1.6.x has some magic that I haven’t fully looked into yet along with the new library layouts.)

1) So I could generate a set of about 10 libraries that play nicely together, several of which would be independently usable outside of OpenTRV (security, OW, radio), but for which versions will need to be carefully managed.

2) Or I could generate one big fat library with everything in it.

3) Or somewhere in between.

4) Or I could repeat something that I’ve done before and create and manage the ~10 libraries separately but then also mechanically generate a ‘combo’ library with all the parts folded together at sensible versions as ‘curated’ by me, for example.

Clearly the most engineering-minded might prefer (1).  The wider audience of tinkerers I hope to keep OpenTRV accessible to might prefer (2) or (4); frankly after a busy day and as an end user of the libraries I might too!

There are internal pros and cons of each arrangement also, of course.

I’d be interested to know the crowd wisdom / preferences re the above.



More information about the OpenTRV-dev mailing list