Using the content write interface

[Benjamin M Romer]

On 08/30/2016 04:58 PM, Mark Shuttleworth wrote:
> The content interface itself is very new, so I suspect the details are
> still flexible based on this sort of feedback and experience. So thank
> you for kick the tires :)

I'd like to think of it as shining the tires. :)

> In general I would say it's unlikely that sharing the entire $SNAP_DATA
> is desirable.

What I had in mind here are applications similar to BOINC, where the 
data to be processed is downloaded from outside and shouldn't be 
processed under the management application's security model. The 
download area could be opened using the content interface, with each 
client project inside its own snap for isolation.

This approach could also be used by services like mail spools and 
message or print queues, or services that work like FTP or Wordpress, 
where files are uploaded but need to be accessible to plug-ins or other 
services (like DLNA for a media server, or HTTP, or ClamAV).

> I suspect that the interface is more aimed at:
>
>  * common builds of shared libraries for large frameworks like ROS and
> Qt and KDE
>  * shared large data sets (for example texture files in a game system)
>
> Mark
>

I've worked with QT in snaps a little, and that would be really good, 
it'd save a lot of space! :) Having a shareable data area for the QT 
snap could give users a way to install custom themes at the system 
level, or make it easier for user-defined external tools to integrate 
with a snap of the SDK's IDE. I think it'd be nice to have. :)

-- Ben