Well, I think we&#39;re talking like ships passing in the night =) so I&#39;ll take another stab at it.<div><br></div><div>If we are talking about a developer grabbing, say, dojox.string as a package to use in development, then I&#39;d expect an interaction like MooForge: you find what you&#39;re looking for, you download a zip/tarball, you receive instructions on where to put it and how to use it, and you add it to your dev setup so that you can use it.  And like the Forge, getting up and running with it is basically a breeze if you know the system that you&#39;re working with.</div>
<div><br></div><div>At that point we&#39;re talking about defining a &quot;package&quot; as something that you can grab and use, but is a little smarter; it knows its own dependencies, and either comes with those dependencies or alerts you when those dependencies aren&#39;t there (and hopefully where to get them).</div>
<div><br></div><div>If we are talking about module structure (i.e. how to load things such as the current dojox.charting as an example), I don&#39;t see any reason why we&#39;d need anything special outside of whatever loader we end up using.  In other words, we have two separate problems: how to get external-ish code into a place where it can be developed against, and how to continue the evolution of the DTK loading system.  I think it&#39;d be nice to be able to say &quot;I want to try out X&quot; by using a discovery/x-domain tool, but at the same time I think it&#39;s just as easy to download it, drop it into an app setup and go.  You can always delete it ;)</div>
<div><br></div><div>At that point it becomes a question of how to discover new packages, whether they will solve a problem for the dev or not, and making sure they are described/searchable (plus a trust factor).</div><div>
<br></div><div>I guess in the end it depends on how someone defines &quot;package&quot;.  Your descriptions have made me think linux/python-ish things, and I don&#39;t know that&#39;s what we need to do...anyways, food for thought.</div>
<div><br></div><div>Regards,</div><div>Tom<br><br><div class="gmail_quote">On Wed, Aug 25, 2010 at 7:54 PM, James Burke <span dir="ltr">&lt;<a href="mailto:jburke@dojotoolkit.org">jburke@dojotoolkit.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">2010/8/25 Tom Trenka &lt;<a href="mailto:ttrenka@gmail.com">ttrenka@gmail.com</a>&gt;:<br>
</div><div class="im">&gt; BTW, I think you&#39;re right (@James) on the idea that a package needs to be<br>
&gt; grabbed at dev time, and deployed as a part of a deployment; being able to<br>
&gt; download and unzip something in a stock directory setup and using even the<br>
&gt; current dojo.require would be fine, as long as it&#39;s not difficult to set up<br>
&gt; with any dependencies said package might have.  I really don&#39;t think we need<br>
&gt; a tool for this, and I&#39;m not entirely sure we need packages to be loadable<br>
&gt; by an application.  And though I have not played with Node or CommonJS, I<br>
&gt; find it hard to believe that you would need to load a package full-on at<br>
&gt; run-time in those environments as well.<br>
&gt; Perhaps we&#39;re over-thinking this a bit?<br>
<br>
</div>Feel free to outline a system you think will work.<br>
<br>
If you think that means dynamically loading package.json files and<br>
parsing them, even though the warnings i gave about issues with<br>
xdomain auth, and that the remote serve may not actually want to be a<br>
runtime file server for your app, feel free to try that out. Working<br>
code helps. Dustin&#39;s branch is a way to try that stuff out. I think it<br>
is not a full test since dealing with dojox modules is under our<br>
control. But perhaps something else can be demonstrated with the<br>
approach.<br>
<br>
I feel like we keep cycling over the same things, so I will stop<br>
talking about them for now. I&#39;m going to code now, to see where things<br>
fall apart.<br>
<div><div></div><div class="h5"><br>
James<br>
_______________________________________________<br>
dojo-contributors mailing list<br>
<a href="mailto:dojo-contributors@mail.dojotoolkit.org">dojo-contributors@mail.dojotoolkit.org</a><br>
<a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
</div></div></blockquote></div><br></div>