<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 7, 2014 at 3:35 AM, Mark Abraham <span dir="ltr"><<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><div class="">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div dir="ltr">
<div>We already have some of our I/O functionality available as separate libraries. If we make our custom analysis functionality available, I'd much rather do that as a Python extension, or as a contribution to a dedicated MD-analysis project. mdrun... might
never achieve a better "API" than grompp.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>I think a Python API for the analysis library would be great. But I think the way we should do it, is wrap the API we have. Thus I don't think a Python extension is a reason against a C/C++ API but a reason for it.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div><div>Sure, but the "API" we have seems like it is just a collection of everything that existed at some point. I'm not against having a public, stable API, but I am against preserving the existing "API" if it delivers little value internally or externally, and
is an impediment to building software that might later be able to get an API worth having.</div></div></div></div></div></blockquote><div><br></div><div>I wouldn't mind removing some of the legacy stuff from the public API. In fact I did that in the past myself (e.g. removing the tmpi header from behing installed). And of course it isn't a real API. But I'm not sure how much work we would safe by removing it. Especially if it is clear to everyone that the legacy API isn't meant to be stable. The changes currently in gerrit (e.g. 3768, 3762, 3750) are about the new API. Thus unless you would also remove the new API (which I think would be a bad idea) you wouldn't safe that work.</div>
<div><br></div><div>Roland</div></div><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309
</div></div>