<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 8:45 AM, Jesse Noller <span dir="ltr"><<a href="mailto:jesse.noller@rackspace.com" target="_blank">jesse.noller@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word"><div><div>After speaking with people working on OSC and looking at the code base in depth; I don’t think this addresses what Chris is implying: OSC wraps the individual CLIs built by each project today, instead of the inverse: a common backend that the individual
 CLIs can wrap - the latter is an important distinction as currently, building a single binary install of OSC for say, Windows is difficult given the dependency tree incurred by each of the wrapped CLIs, difference in dependencies, structure, etc.</div>
</div></div></blockquote><div><br></div><div>OSC is the top of the cake and was the most beneficial to user experience so it went first.  I would love to consume fewer libraries and dependencies, so much that I still have a project to do this in a language that can easily ship a single binary client.</div>
<div><br></div><div>What I think we're talking about here is the bottom of the cake and eliminating duplication and accumulated cruft from repeated forking and later direction changes.</div><div><br></div><div>The creamy gooey middle is the API-specific bits that right stay exactly where they are (for now??) and can continue to ship a stand-alone cli if they wish.</div>
<div> </div><div>dt</div></div><div><br></div>-- <br><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
</div></div>