<p dir="ltr">+1 to Brad's comments. I don't see the need for this.</p>
<div class="gmail_quote">On Mar 20, 2014 8:30 AM, "Bradley Lowekamp" <<a href="mailto:blowekamp@mail.nih.gov">blowekamp@mail.nih.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Matt,<br>
<br>
It's not clear to me what is motivating this change. What is the advantage, what could we do that we can't currently do now?<br>
<br>
I think there are quite a number of ways modules could be improved. High on the list to to make them usable outside of ITK. This would enable people to develop a module as part of an application, share it on github, then integrated into ITK. As opposed to now, a module it no  useful outside of ITK.<br>

<br>
Additionally, we should look at the large term goals. Slicer has done some nice things with the Extension Index. This include having it as a separate repo, where contributions can go to prior stable releases. As a long term goal I'd like to see the Insight Journal function in some ways as the Extension Index.<br>

<br>
Brad<br>
<br>
On Mar 19, 2014, at 10:09 PM, Matt McCormick <<a href="mailto:matt.mccormick@kitware.com">matt.mccormick@kitware.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> I would like to propose improving the Remote Module file format and<br>
> get some feedback.<br>
><br>
> Currently, the file is a short direct call to a CMake function with<br>
> some basic parameters [1].<br>
><br>
> Learning from what has been done with the Slicer Extension Index [2],<br>
> I propose we separate the data cleanly, then call the CMake function<br>
> on the data.  The format could be simple INI-style key-value pairs, so<br>
> it can be parsed easily with CMake and other programming languages.<br>
><br>
> This would make it easier to know what fields are expected.  It would<br>
> also allow other programming languages to parse the file for the<br>
> purposes of making a web page listing, other clients, etc.<br>
><br>
> Fields could be:<br>
><br>
>  name<br>
>  description<br>
>  documentation_url<br>
>  repository_url<br>
>  revision<br>
>  contributors<br>
>  status<br>
>  group<br>
><br>
> Thoughts?<br>
><br>
> Thanks,<br>
> Matt<br>
><br>
><br>
> [1] <a href="http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Remote/SmoothingRecursiveYvvGaussianFilter.remote.cmake;h=130d13e99c19789f0420b4558e34131cad39f3a4;hb=HEAD" target="_blank">http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Remote/SmoothingRecursiveYvvGaussianFilter.remote.cmake;h=130d13e99c19789f0420b4558e34131cad39f3a4;hb=HEAD</a><br>

><br>
> [2] <a href="https://github.com/Slicer/ExtensionsIndex/blob/master/ChangeTracker.s4ext" target="_blank">https://github.com/Slicer/ExtensionsIndex/blob/master/ChangeTracker.s4ext</a><br>
> _______________________________________________<br>
> Community mailing list<br>
> <a href="mailto:Community@itk.org">Community@itk.org</a><br>
> <a href="http://public.kitware.com/cgi-bin/mailman/listinfo/community" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/community</a><br>
<br>
_______________________________________________<br>
Community mailing list<br>
<a href="mailto:Community@itk.org">Community@itk.org</a><br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/community" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/community</a><br>
</blockquote></div>