Thanks Matthias - please see inline. <br><br><div class="gmail_quote">On Tue, Jul 27, 2010 at 7:03 PM, Matthias Felleisen <span dir="ltr"><<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</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><br></div><div>1. a 'remote url' require (which is what Planet boils down to) imposes a serious cost overhead (for compilation) and a connectivity overhead (suppose I send you code and you wish to compile it on your netbook while on the subway). People who get this kind of code should be aware of it. At a minimum, the path should start with /planet/ and that'll set it apart. (There's more, such as versioning.) </div>
</div></blockquote><div><br></div><div>Location non-transparency matters a lot in remote API calls since each calls incurs non-trivial network overhead. However, the 'remote url' require is only remote the *very first time*; once compiled it exists in cache and hence incur no additional overhead. Whereas the planet prefix incur the awareness overhead every single time. I.e., the cost is greater than the benefit.</div>
<div><br></div><div>Other package systems separate the installation step from the import step, and in such systems the subsequent use of the package appears exactly the same as a local package. </div><div><br></div><div>
If we want `require` to continue to handle both first-time install and subsequent import, and we wish to unify the syntax, then what we can do is to make the first time "interactive" - i.e. when we require a package that has not been cached, we can prompt the user saying "this package resides on planet - do you wish to download and continue the installation?". There are probably better UI approaches, but that's an idea. </div>
<div><br></div><div>For versioning - any explicit version can be cached in planet style, and all version exists on planet systems. What this means is once planet and collects unify, you can have the different versions of collects packages living in planet. </div>
<div><br></div><div> </div><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><div>2. it is easy to find and fix collects code. Planet's download mechanism would have to change a lot to enable that. </div>
<div><div></div><div class="h5"><div><br></div></div></div></div></blockquote><div><br></div><div>This is the cultural issue that I am talking about. To use other people's code there needs to be trust that other people's code will be supported. The trust won't be built over night, but you also will not start using other people's code en masse. So there is time to build that trust. </div>
<div><br></div><div>At first, most likely you will only try out a few packages, and probably from people that are already contributing to the collects packages, since you know them. But then eventually you will be able to include more people once the approach is understood and tested. </div>
<div><br></div><div>Currently - the above is not possible at all since the platform prohibits it. So the platform needs to be fixed first before the culture will change. </div><div><br></div><div>If direct source tree access is desired, then perhaps providing a planet source control system for module writers to opt-in for packages that become candidates to be included in the core system can be a requirement. </div>
<div><br></div><div>This probably looks like a lot of chores at first, but the community can grow this way by giving module writers a chance to participate. </div><div><br></div><div>My 2 cents. Cheers,</div><div>yc</div>
<div><br></div></div>