<div class="gmail_quote">On Thu, Jan 14, 2010 at 3:45 PM, Carl Eastlund <<a href="mailto:carl.eastlund@gmail.com" target="_blank">carl.eastlund@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">YC, I think most of us PLT developers would like to be able to integrate Planet and the collections, such that PLT products could import Planet packages, and be exported as Planet packages. This has been a desire of ours for some time. However, this would take a significant rearrangement of our infrastructure. We would also have to clarify the issues of intellectual property for Planet packages. It will take time and resources we simply have not yet had a chance to invest. I don't think there is a plan on the horizon right now, but we do agree with you that there's a lot of untapped potential. Hopefully we'll have a chance to take greater advantage of it soon.</blockquote> <div> Thanks Carl for the comments. It seems there might be a keep-it-simple solution initially: <ul><li>Map all collects path as a shorthand of a planet path </li> <ul><li>Example - scheme/base might equate to something like (planet scheme/base), or (planet core/scheme/base) </li></ul><li>Make the planet search through collects 1st for code loading, then the planet cache, and finally planet repository </li></ul>The above will blur the difference between a collects path and a planet path, which will allow all existing code to gracefully migrate between collects and planet without change. W.r.t the IP issue, you would have to evaluate whether to use the external modules on case-by-case basis anyways, so this would be just one more thing on the checklist (i.e. is the module released in a compatible license that can be included). This is not a technical issue, but blurring the distinctions between the 2 paths will allow you to make such evaluations going forward. The main issue I see with this approach is the potential for name collision between planet modules and collects, which can be resolved with some sort of mapping (either by convention or configuration) that would needed to be hashed out. Otherwise AFAICT this can serve as a good starting point. I might be over simplifying the issue here, so would love to hear thoughts/comments/critiques. Thanks, yc </div></div>