<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 12, 2016 at 1:35 PM, Mark Shuttleworth <span dir="ltr"><<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":5w7" class="">Interfaces should actually handle this case very well, as long as both<br>
sides of the file exchange are predictable. So I can imagine CUPS<br>
providing an interface to ingest PPDs and a PPD snap that consumes that<br>
interface making the PPDs available.<br>
<br>
In the next wave of landings, you'll see the ability to execute code in<br>
both snaps when an interface is being connected, allowing you to agree<br>
for example on filenames etc.</div></blockquote></div><br>Ack: In any pure snap setup the interface based solution would have been my way to go for this. And it certainly is the right one.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In the context of the request I was thinking more about snaps on classic and how e.g. a "classic" system could pick up those.</div><div class="gmail_extra">Or turning around the statement: How a snap would ensure things are picked up by the "host" in classic.</div><div class="gmail_extra"><br></div><div class="gmail_extra">A generic solution for this isn't the most important feature - as it might also break isolation more than we like.</div><div class="gmail_extra">So - if considered as a generic feature - this might just end up as one of the constraints for snaps on classic.<br></div><div class="gmail_extra">But for a few common cases (like manpages see bug 1575593 I think we should design and provide something that can be commonly used).</div><div class="gmail_extra"><br clear="all"><div>Looking forward for the next wave of landings then - maybe the "active interface connect" if we want to call it that way would already provide enough to solve it that way.</div><div><br></div>
</div></div>