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 -- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
