<div dir="ltr"><div>So you're suggesting to try to speak the IPython protocol and somehow thread task descriptions through that and run the command-line app on the other end?<br><br>It's partially documented but they seem a little vague about backwards compatibility and whether it's an official public interface. <br>

<a href="http://ipython.org/ipython-doc/2/development/messaging.html" target="_blank">http://ipython.org/ipython-doc/2/development/messaging.html</a><br><br></div><div>Aside from It seems that it would be difficult (impossible?) to build things like provider staging on top of this.<br>

</div><div><br></div><div>I just tend to think that trying to integrate with existing code causes at least as many problems as it solves unless the other system was really carefully designed to be a building block for other systems.  The design seems to assume throughout that your tasks are going to be a Python function.  If anything we might want something that provides lower-level functionality that isn't specialised for running Python functions.<br>
<br></div><div>- Tim<br>
</div><div><br></div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 29, 2014 at 1:47 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</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">I was exploring AMQP as an alternative to writing my own protocol (which<br>
turned out to be coasters) somewhere before I started working on Swift.<br>
In spirit, it seemed to do exactly what I wanted. Unfortunately, there<br>
were no reasonable implementations at the time, which I see has changed.<br>
<br>
So I do think this is worth exploring although I'm not quite sure about<br>
the moving parts part. The outsides of things can be deceiving.<br>
<br>
Mihael<br>
<div><div><br>
On Thu, 2014-05-29 at 10:47 -0500, Michael Wilde wrote:<br>
> [Moving this part of the discussion to a new thread.]<br>
><br>
> Seems like less moving parts than coasters: it would all be in Python<br>
> (instead of Java + Perl); would have iPython community support; and<br>
> would be based on a standard protocol (ZeroMQ implementation of AMQP).<br>
><br>
> iPython parallel has almost the exact same process architecture as Swift<br>
> Coasters.<br>
><br>
> Seemed worth exploring.<br>
><br>
> - Mike<br>
><br>
> On 5/29/14, 10:28 AM, Tim Armstrong wrote:<br>
> > ...<br>
> ><br>
> > What's the motivation for the IPython idea? It feels like a lot of moving<br>
> > parts to me.<br>
> ><br>
> > - TIm<br>
> ><br>
><br>
</div></div>> _______________________________________________<br>
> Swift-devel mailing list<br>
> <a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
> <a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
<br>
<br>
</blockquote></div><br></div></div></div>