RFC: hybrid and context sensitive snaps
ogra at ubuntu.com
Tue Oct 27 13:35:56 UTC 2015
during our presentation at ubucon I was showing my ircproxy snap to demo
snapcraft. one of my plans with this snap is to act as a backend service
for a phone app.
the current snap ships a bip installation that is fully manageable with
snappy config, the plan is to also pull a kiwi irc client installation
(a nodejs based web client) into this package that will be hardwired to
this bip proxy and to which a phone app will then connect via https and
authentication. that way you will have the long running backend service
operating on your home or cloud snappy install while the UI part on the
phone can be suspended and re-activated to your liking without losing
the actual IRC connection and without losing any pings or backlog.
today I would have to create one snap and one click package for this
setup, maintaining the backend service and the UI app in two different
packages and (possibly) separate bzr/git trees.
after the presentation I was approached about this design and the
question came up if it wouldn't be possible to have all of it in the
same snap and source tree (in the light that the phone will eventually
switch to snap instead of click packages).
I personally think it would be an awesome idea and support our
convergence plans pretty well if it would be possible to have both parts
of such a setup in a single snap that can enable only parts of the
shipped bits depending on the context it is installed in ... i.e. if
installed on a headless snappy RPi or cloud instance, only the server
bits would be enabled, if installed on a phone it would only activate
the UI side of things ...
what do people think, would such a feature make sense in general in snap
packages (I think it would) or am I having a brainfart here ? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 173 bytes
Desc: This is a digitally signed message part
More information about the snappy-devel