(Not entirely) working LDC snap

[Joseph Rushton Wakeling]

On 06/09/16 00:53, Mark Shuttleworth wrote:
> There is a balance - the upside of having a "sandbox" /lib/ is that it
> is *the same everywhere* even if your snap is running on openwrt.
>
> But for this class of developer tool, snaps will be much more useful if
> they can really integrate into the CLASSIC environment.
>
> We'll get to this. My straw man proposal is an interface which
> essentially makes "/classic/lib/" and "/classic/bin/" available to your
> snap, so as long as your snap's $PATH is twisted appropriately it will
> find things there. That's a proper bit of yoga on where snaps came from
> and how we got them onto classic in the first place, but I think it has
> merit as a starting point.

Yea, makes sense.  It'll be fun to play with when it's ready :-)

There was an idea that occurred to me, which I'm not sure necessarily fits with 
the snappy vision, but here goes.  The metaphor for interfaces is plugs and 
sockets -- which suggests one to one connections.  But where things like 
development libraries are concerned, one could imagine this more like posts on a 
bulletin board: the individual services post their availability via a particular 
board (in this case, the "development library" board), and snaps interested in 
consuming a particular class of service can find out about and access all the 
services of a particular kind by asking to read the associated board.

IOW instead of requesting access to one particular interface, snaps could 
request access to collections of services, and other snaps could add individual 
services to a given collection.

This could be an interesting way to make development libraries available without 
relying on an underlying "classic" system.

> On the other hand, snapping redis, rethinkdb and rqlite has gone really
> smoothly :)

Nice!  Congratulations :-)