Frameworks in Ubuntu Core

[Mark Shuttleworth]

On 21/10/15 03:05, Víctor Mayoral Vilches wrote:
> Size actually is a problem if we think of extending a robot's behavior
> with snaps. The main reason why we haven't pushed ROS snaps to the
> store is because it doesn't make sense to have a 200 MB simple ROS
> package (or even 50 MB if we manually strip it down). Updating it
> wirelessly sounds even less plausible (which is what really excites
> me). Besides the size of the snaps, right now, I also have to admit
> that doing ROS development in Snappy is extremely time consuming. The
> problem with including the library inside the framework is that 

Yes, I see the use case you outline.

We have been very focused on "loose coupling" between snaps, to avoid
the sort of dependency hell that plagues both Windows and Ubuntu
traditional deb packages.

In this context, a framework would make sense for you if it was YOUR
framework. In other words, I think it would make sense to have a
"cluster of snaps" which are tightly coupled; that means that you would
QA any updates to your framework and apps together as a single story. It
also means that other snaps wouldn't want to use that framework because
it could change at any time and would be tightly coupled to

So, I will ask the team to explore this sort of tight coupling of
"library frameworks" which provide a big common lump of code to a few
snaps from the same vendor. This keeps the tight coupling in the domain
of a single vendor, enabling that vendor to split things up efficiently
for themselves but still maintain complete control of the stack that
they are shipping.

We will for now avoid tight coupling of snaps across vendor boundaries,
because that's going to lead us back to brittle dependencies and tears.

> It's important to highlight here that when we design software for
> robots using ROS, we build on top of this concept of distributed
> software pieces that may *depend on each other*. This is critical for
> expanding the capabilities of our robots by installing different
> snaps. So if I were to create certain functionality and expose it
> through set of new ROS topics, I'd probably expect to access these ROS
> topics from other snaps in a later stage. Since ROS supports
> TCP/IP-based and UDP-based communications, would it be possible to
> access ROS topics from other snaps? Can I inspect the ROS packages
> installed in the overall system? It'll probably make sense to have
> rosbash <http://wiki.ros.org/rosbash> tools installed within Snappy so
> that they can inspect ROS abstractions. While it makes sense to do
> shared maintenance of dependencies, and the 

TCP/IP over 127.0.0.1 would be perfectly feasible today, I think. Have
you explored that?

Does that all seem sensible and a step in the right direction?

Mark