<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <br>
    <br>
    On 8/23/2010 7:03 PM, James Burke wrote:
    <blockquote
      cite="mid:AANLkTintNCBmv4q5qJK9mXEZgdLk=7NmTYFfokY8R6gF@mail.gmail.com"
      type="cite">
      <pre wrap="">Responding to Kris and Dustin's comments, but summarizing:

1) Do not require command-line tool:
In the context of a Dojo 2.0 I think this is fine to deliver the
command line package tool with the loader. Most if not all users will
want to use it. Trying to download a zip manually, unzip it in the
right place then do the app config will just be too tedious. However,
the steps the command line tool does will be documented if people want
to do it themselves. However I expect almost no one to actually
manually do the steps.
</pre>
    </blockquote>
    I think this might be somewhat of an underestimation of developers
    prowess at being able to unzip and copy files. With the frequency of
    difficulty with getting command line tools to work properly, I
    wouldn't be surprised to see a lot of user manually unpacking
    packages. the world is never as ideal as we would hope, and manual
    methods always get more use than one would expect.<br>
    <br>
    <blockquote
      cite="mid:AANLkTintNCBmv4q5qJK9mXEZgdLk=7NmTYFfokY8R6gF@mail.gmail.com"
      type="cite">
      <pre wrap="">
2) Allow parsing package.json files in the browser as part of a running web app:
There are too many caveats with this approach to make desirable: the
server needs to allow xdomain use, or the server has to offer some
xdomain-safe equivalent, the modules have to be in the module format
expected by the loader (for instance if RequireJS is used, then the
modules cannot be plain CommonJS modules)</pre>
    </blockquote>
    RequireJS doesn't support plain CommonJS modules anyway does it?<br>
    <blockquote
      cite="mid:AANLkTintNCBmv4q5qJK9mXEZgdLk=7NmTYFfokY8R6gF@mail.gmail.com"
      type="cite">
      <pre wrap="">, and the package host needs
to be comfortable being a mini-CDN. If the command-line package tool
is available with the loader, then it is just simpler to always
instruct the developer to use that. To me, the on-the-fly in-browser
package.json parsing's benefit is out-weighed by the number of rough
edges and documentation/communication it requires to use it
effectively.
</pre>
    </blockquote>
    <br>
    Meaning you wouldn't use it for a production app, or you don't want
    any developer to ever have the option of using for development or
    otherwise?&nbsp; Did you see the patch [1], its about a dozen lines of
    code and we could easily default it out of the build or move it out
    base, making the cost almost nil.&nbsp; I don't have any expectation that
    this would be the most commonly used or the first recommendation for
    including packages, but when you consider that this could be the
    quickest way for many developers to utilize packages (no download or
    execution required) and could have some powerful uses in certain
    situations (like in Intranets with shared libraries), I find it hard
    to see how we would doing our users a favor by denying them this
    option. <br>
    <br>
    [1]<a
      href="http://bugs.dojotoolkit.org/attachment/ticket/11584/packages.diff">
      http://bugs.dojotoolkit.org/attachment/ticket/11584/packages.diff</a><br>
    <br>
    Thanks,<br>
    Kris<br>
  </body>
</html>