Nowadays many people in the dojo community is making their own
projects in github. We plan for many of those projects to "be part
of dojo 2.0": https://github.com/jrburke/requirejs,
https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
maybe parts of https://github.com/phiggins42/plugd. (Also perhaps
https://github.com/phiggins42/mustache.js,
https://github.com/kriszyp/compose,
https://github.com/kriszyp/objectable,
https://github.com/dmachi/virtual-datalist, ...)

I'm just wondering, how will this all work? Will there still be a
single repository for dojo core (or if they are separate repositories,
how will permissions work)? Will there still be a single dojo core
release? Will there still be something called "dojo toolkit" at
least from a marketing angle?

I know that we plan to release the dojox projects as separate
packages, but how many packages will people need to download to get
(what today we call) dojo core?

Search Discussions

  • Tom Trenka at Dec 2, 2010 at 9:23 pm
    I think the basic game plan (once 2.0 really starts taking shape) is to be
    able to collect a set of packages that we'd call "Dojo Toolkit 2.0", and
    gather them for a single release point that would be grabbed the same way
    distributions are downloaded now...so a set of packages of whatever we call
    "core", the set of packages that collectively make up Dijit, and selected
    (current) DojoX projects. The latter would be what we consider to be most
    important from a marketing standpoint (such as gfx and charting, should they
    remain separate github-maintained projects), and would serve as examples of
    how to "install" your own packages.

    Does that help?

    Regards--
    Tom
    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still be a
    single repository for dojo core (or if they are separate repositories,
    how will permissions work)? Will there still be a single dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101202/c92f4138/attachment.htm
  • Bill Keese at Dec 2, 2010 at 10:39 pm
    Sure, that helps, I guess I was also expecting to keep the dojo name
    brand, and to keep doing bundled releases of core and dijit (wasn't
    expecting anything from dojox but I don't care either way).

    I still wonder though... dojo was founded with the idea/ideal of
    everyone checking in code to a common codebase to build a toolkit
    together. Now we have a bunch of individual projects each owned by
    one person; each owner's name is actually in the URL to the project.
    I guess individual project owners have been the reality of most of
    dojo for a while but now (for example) I couldn't even check in a
    documentation update to dojo base (aka pulsar) since I don't have
    permission on that github project.

    The other trend I noticed is that no one wants to tie their code to
    dojo. For example, requireJS, has.js, both dojo.query engines, and
    the scrolling code added to mobile are all designed to run
    independently. I can't blame people for doing that since it's a
    good marketing move, especially given jQuery's dominance, but it feels
    weird.

    Anyway, that's not really a question, just food for thought.

    2010/12/3 Tom Trenka <ttrenka at gmail.com>:
    I think the basic game plan (once 2.0 really starts taking shape) is to be
    able to collect a set of packages that we'd call "Dojo Toolkit 2.0", and
    gather them for a single release point that would be grabbed the same way
    distributions are downloaded now...so a set of packages of whatever we call
    "core", the set of packages that collectively make up Dijit, and selected
    (current) DojoX projects. ?The latter would be what we consider to be most
    important from a marketing standpoint (such as gfx and charting, should they
    remain separate github-maintained projects), and would serve as examples of
    how to "install" your own packages.
    Does that help?
    Regards--
    Tom
    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. ? ?We plan for many of those projects to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. ? (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? ? Will there still be a
    single repository for dojo core (or if they are separate repositories,
    how will permissions work)? ? Will there still be a single dojo core
    release? ? ?Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Adam L. Peller at Dec 2, 2010 at 10:55 pm

    On Thu, Dec 2, 2010 at 10:39 PM, Bill Keese wrote:

    I still wonder though... dojo was founded with the idea/ideal of
    everyone checking in code to a common codebase to build a toolkit
    together. Now we have a bunch of individual projects each owned by
    one person; each owner's name is actually in the URL to the project.
    I think I was told that we could employ distribution lists in github to
    share access lists and provide a shared sense of ownership, at least for a
    set of projects we consider our own; OTOH community members could freely go
    and develop their own extensions under their own name with or without our
    approval, so the community doesn't have to be bound by our capacity to
    review code and do system administration. This would also make it possible
    to have different access lists for different parts of the project... core vs
    dijit vs other extensions.

    The other trend I noticed is that no one wants to tie their code to
    dojo. For example, requireJS, has.js, both dojo.query engines, and
    the scrolling code added to mobile are all designed to run
    independently. I can't blame people for doing that since it's a
    good marketing move, especially given jQuery's dominance, but it feels
    weird.
    There are obviously tradeoffs to toolkit neutrality, though I think you can
    only take toolkit pluggability so far. But at the bootstrap level (esp.
    requirejs) neutrality is a big win. In a perfect world, it could lead to
    interoperability between toolkits and distribution systems.

    -Adam
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101202/8becaa90/attachment.htm
  • Eugene Lazutkin at Dec 2, 2010 at 11:08 pm
    You are forgetting that we have "Dojo" account on github, which is an
    organization account with individual members. All official components
    are going to be published there under Dojo. Right now it publishes
    read-only mirrors, so we don't add all committers to the list, but
    eventually it will publish real code, so all committers will be added
    and can work on the repositories directly.

    At the moment we have a bunch of libraries in flux (you listed them),
    and nothing more --- it is not that different from working locally on
    our individual components before we are ready to commit it.

    I like Adam's idea that instead of formally relocating projects to some
    DojoX repository we should have the Dojo seal of approval. That +
    putting it in a special registry to simplify and automate access to
    sub-projects could potentially replace DojoX.

    Cheers,

    Eugene Lazutkin
    http://lazutkin.com/

    On 12/02/2010 09:39 PM, Bill Keese wrote:
    Sure, that helps, I guess I was also expecting to keep the dojo name
    brand, and to keep doing bundled releases of core and dijit (wasn't
    expecting anything from dojox but I don't care either way).

    I still wonder though... dojo was founded with the idea/ideal of
    everyone checking in code to a common codebase to build a toolkit
    together. Now we have a bunch of individual projects each owned by
    one person; each owner's name is actually in the URL to the project.
    I guess individual project owners have been the reality of most of
    dojo for a while but now (for example) I couldn't even check in a
    documentation update to dojo base (aka pulsar) since I don't have
    permission on that github project.

    The other trend I noticed is that no one wants to tie their code to
    dojo. For example, requireJS, has.js, both dojo.query engines, and
    the scrolling code added to mobile are all designed to run
    independently. I can't blame people for doing that since it's a
    good marketing move, especially given jQuery's dominance, but it feels
    weird.

    Anyway, that's not really a question, just food for thought.

    2010/12/3 Tom Trenka <ttrenka at gmail.com>:
    I think the basic game plan (once 2.0 really starts taking shape) is to be
    able to collect a set of packages that we'd call "Dojo Toolkit 2.0", and
    gather them for a single release point that would be grabbed the same way
    distributions are downloaded now...so a set of packages of whatever we call
    "core", the set of packages that collectively make up Dijit, and selected
    (current) DojoX projects. The latter would be what we consider to be most
    important from a marketing standpoint (such as gfx and charting, should they
    remain separate github-maintained projects), and would serve as examples of
    how to "install" your own packages.
    Does that help?
    Regards--
    Tom
    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still be a
    single repository for dojo core (or if they are separate repositories,
    how will permissions work)? Will there still be a single dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Dec 3, 2010 at 12:03 am
    I remember hearing about that github dojo organization account, and I
    understand that we are in the prototyping stage now and things may
    change... but as to your statement:
    All official components
    are going to be published [in the dojo account] under Dojo.
    Not sure how true that is, or what exactly you mean by "published".
    At least some projects (requireJS, has.js etc.) want to remain
    independent rather than being swallowed by dojo. Of course they can
    be copied/linked into dojo/dojo but it's not quite the same, since
    their official home is still outside of dojo/ and they have
    independent marketing, release cycles, etc. (Their only official
    connection is to Dojo Foundation, not to Dojo Toolkit.)

    Perhaps you meant that your pulsar project and the other stuff in dojo
    core will be officially under dojo/dojo?

    Anyway, not saying that's a bad thing, just wondering what it will be like.
    On Fri, Dec 3, 2010 at 1:08 PM, Eugene Lazutkin wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    You are forgetting that we have "Dojo" account on github, which is an
    organization account with individual members. All official components
    are going to be published there under Dojo. Right now it publishes
    read-only mirrors, so we don't add all committers to the list, but
    eventually it will publish real code, so all committers will be added
    and can work on the repositories directly.

    At the moment we have a bunch of libraries in flux (you listed them),
    and nothing more --- it is not that different from working locally on
    our individual components before we are ready to commit it.

    I like Adam's idea that instead of formally relocating projects to some
    DojoX repository we should have the Dojo seal of approval. That +
    putting it in a special registry to simplify and automate access to
    sub-projects could potentially replace DojoX.

    Cheers,

    Eugene Lazutkin
    http://lazutkin.com/

    On 12/02/2010 09:39 PM, Bill Keese wrote:
    Sure, that helps, I guess I was also expecting to keep the dojo name
    brand, and to keep doing bundled releases of core and dijit (wasn't
    expecting anything from dojox but I don't care either way).

    I still wonder though... ? dojo was founded with the idea/ideal of
    everyone checking in code to a common codebase to build a toolkit
    together. ? Now we have a bunch of individual projects each owned by
    one person; each owner's name is actually in the URL to the project.
    I guess individual project owners have been the reality of most of
    dojo for a while but now (for example) I couldn't even check in a
    documentation update to dojo base (aka pulsar) since I don't have
    permission on that github project.

    The other trend I noticed is that no one wants to tie their code to
    dojo. ? For example, requireJS, has.js, both dojo.query engines, and
    the scrolling code added to mobile are all designed to run
    independently. ? ?I can't blame people for doing that since it's a
    good marketing move, especially given jQuery's dominance, but it feels
    weird.

    Anyway, that's not really a question, just food for thought.

    2010/12/3 Tom Trenka <ttrenka at gmail.com>:
    I think the basic game plan (once 2.0 really starts taking shape) is to be
    able to collect a set of packages that we'd call "Dojo Toolkit 2.0", and
    gather them for a single release point that would be grabbed the same way
    distributions are downloaded now...so a set of packages of whatever we call
    "core", the set of packages that collectively make up Dijit, and selected
    (current) DojoX projects. ?The latter would be what we consider to be most
    important from a marketing standpoint (such as gfx and charting, should they
    remain separate github-maintained projects), and would serve as examples of
    how to "install" your own packages.
    Does that help?
    Regards--
    Tom
    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. ? ?We plan for many of those projects to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. ? (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? ? Will there still be a
    single repository for dojo core (or if they are separate repositories,
    how will permissions work)? ? Will there still be a single dojo core
    release? ? ?Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAkz4bSYACgkQY214tZwSfCvaDgCeM1IExD5IbFwcex13e9Coo4VP
    PgsAoLARokWEInPpAjF1vuQ8/LhrNS9C
    =0XbG
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Eugene Lazutkin at Dec 3, 2010 at 12:33 am
    Inline.
    On 12/02/2010 11:03 PM, Bill Keese wrote:
    I remember hearing about that github dojo organization account, and I
    understand that we are in the prototyping stage now and things may
    change... but as to your statement:
    All official components
    are going to be published [in the dojo account] under Dojo.
    Not sure how true that is, or what exactly you mean by "published".
    At least some projects (requireJS, has.js etc.) want to remain
    independent rather than being swallowed by dojo. Of course they can
    be copied/linked into dojo/dojo but it's not quite the same, since
    their official home is still outside of dojo/ and they have
    independent marketing, release cycles, etc. (Their only official
    connection is to Dojo Foundation, not to Dojo Toolkit.)
    I suspect that we will host snapshots of vital elements, and these
    snapshots will be actively supported. Obviously other schemes can be
    used instead. In any case I want Dojo to be a one-stop shop, as it is
    now, rather than a recipe "go in 25 places, download stuff, and see if
    it works for you".
    Perhaps you meant that your pulsar project and the other stuff in dojo
    core will be officially under dojo/dojo?
    That's the intention --- after the initial engineering phase, I want it
    to be reviewed, approved, polished, and moved to Dojo. I do not intend
    to continue its development as an independent entity.

    Cheers,

    Eugene

    Anyway, not saying that's a bad thing, just wondering what it will be like.

    On Fri, Dec 3, 2010 at 1:08 PM, Eugene Lazutkin wrote:
    You are forgetting that we have "Dojo" account on github, which is an
    organization account with individual members. All official components
    are going to be published there under Dojo. Right now it publishes
    read-only mirrors, so we don't add all committers to the list, but
    eventually it will publish real code, so all committers will be added
    and can work on the repositories directly.

    At the moment we have a bunch of libraries in flux (you listed them),
    and nothing more --- it is not that different from working locally on
    our individual components before we are ready to commit it.

    I like Adam's idea that instead of formally relocating projects to some
    DojoX repository we should have the Dojo seal of approval. That +
    putting it in a special registry to simplify and automate access to
    sub-projects could potentially replace DojoX.

    Cheers,

    Eugene Lazutkin
    http://lazutkin.com/

    On 12/02/2010 09:39 PM, Bill Keese wrote:
    Sure, that helps, I guess I was also expecting to keep the dojo name
    brand, and to keep doing bundled releases of core and dijit (wasn't
    expecting anything from dojox but I don't care either way).

    I still wonder though... dojo was founded with the idea/ideal of
    everyone checking in code to a common codebase to build a toolkit
    together. Now we have a bunch of individual projects each owned by
    one person; each owner's name is actually in the URL to the project.
    I guess individual project owners have been the reality of most of
    dojo for a while but now (for example) I couldn't even check in a
    documentation update to dojo base (aka pulsar) since I don't have
    permission on that github project.

    The other trend I noticed is that no one wants to tie their code to
    dojo. For example, requireJS, has.js, both dojo.query engines, and
    the scrolling code added to mobile are all designed to run
    independently. I can't blame people for doing that since it's a
    good marketing move, especially given jQuery's dominance, but it feels
    weird.

    Anyway, that's not really a question, just food for thought.

    2010/12/3 Tom Trenka <ttrenka at gmail.com>:
    I think the basic game plan (once 2.0 really starts taking shape) is to be
    able to collect a set of packages that we'd call "Dojo Toolkit 2.0", and
    gather them for a single release point that would be grabbed the same way
    distributions are downloaded now...so a set of packages of whatever we call
    "core", the set of packages that collectively make up Dijit, and selected
    (current) DojoX projects. The latter would be what we consider to be most
    important from a marketing standpoint (such as gfx and charting, should they
    remain separate github-maintained projects), and would serve as examples of
    how to "install" your own packages.
    Does that help?
    Regards--
    Tom
    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still be a
    single repository for dojo core (or if they are separate repositories,
    how will permissions work)? Will there still be a single dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    >>
  • Adam L. Peller at Dec 2, 2010 at 10:48 pm
    I've got a more minimalist view, that we'd adopt the model where we have a
    small, stable core (dojo.js) not unlike jquery, and plugins from the
    community, each one we can choose to manage ourselves or let the community
    run as appropriate. We could choose to call the whole thing Dojo toolkit or
    some set profile, though I don't think we should try to package anything
    like what we have in DojoX today. Instead, tools (like the webbuilder tool
    James is working on) should make it easy to download and use what you need.
    Each DojoX subproject (no longer called DojoX) could be marketed and
    developed on its own, some with the Dojo seal of approval and some without,
    each free to do its own release cycle, marketing and maintenance. In this
    way, I would think Dijit would be packaged like any other subproject, but
    clearly one with a lot of importance. That wouldn't prevent someone from
    packaging certain useful profiles for download, but I would hope the Dojo
    toolkit would no longer be looked at as one big zip file. Dijit might very
    well be offered as a medium-size distribution with a set of required Dojo
    core packages.

    -Adam


    2010/12/2 Tom Trenka <ttrenka at gmail.com>
    I think the basic game plan (once 2.0 really starts taking shape) is to be
    able to collect a set of packages that we'd call "Dojo Toolkit 2.0", and
    gather them for a single release point that would be grabbed the same way
    distributions are downloaded now...so a set of packages of whatever we call
    "core", the set of packages that collectively make up Dijit, and selected
    (current) DojoX projects. The latter would be what we consider to be most
    important from a marketing standpoint (such as gfx and charting, should they
    remain separate github-maintained projects), and would serve as examples of
    how to "install" your own packages.

    Does that help?

    Regards--
    Tom

    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still be a
    single repository for dojo core (or if they are separate repositories,
    how will permissions work)? Will there still be a single dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101202/442b7e4f/attachment-0001.htm
  • Sasha Firsov at Dec 2, 2010 at 11:53 pm
    Adam,
    In my past of corporate environment the presence of stable and
    sufficient feature set (including widgets) was one of key decision
    making points on selection which JS library to use.
    jQuery is suffering from the model you described. With zillions of
    plugins available, there is no chance to find enough basic ones matching
    core release. Dojo in that respect is quite more reliable. Having common
    release and life cycle for core, dijit and all dojoX is a major advantage.
    As far as I know there is a branch for experimental packages until they
    eventually will be promoted to dojoX and may be further.
    Making 3-rd party widgets/libraries listed and accessible over own
    registrar is a great idea, but not at cost of integrity of dojo as a whole.
    Just check how CSS thread goes over all branches. It has a perfect sense
    to keep them as solid entity.

    The independent development offered by git does not prevent to have
    stable release for whole toolkit and local/temporary branching for
    ongoing stuff. I guess everyone on thread is well aware of what
    distributed CMS (like git or mercurial) could offer.
    -Sasha
    On 12/2/2010 7:48 PM, Adam L. Peller wrote:
    I've got a more minimalist view, that we'd adopt the model where we
    have a small, stable core (dojo.js) not unlike jquery, and plugins
    from the community, each one we can choose to manage ourselves or let
    the community run as appropriate. We could choose to call the whole
    thing Dojo toolkit or some set profile, though I don't think we should
    try to package anything like what we have in DojoX today. Instead,
    tools (like the webbuilder tool James is working on) should make it
    easy to download and use what you need. Each DojoX subproject (no
    longer called DojoX) could be marketed and developed on its own, some
    with the Dojo seal of approval and some without, each free to do its
    own release cycle, marketing and maintenance. In this way, I would
    think Dijit would be packaged like any other subproject, but clearly
    one with a lot of importance. That wouldn't prevent someone from
    packaging certain useful profiles for download, but I would hope the
    Dojo toolkit would no longer be looked at as one big zip file. Dijit
    might very well be offered as a medium-size distribution with a set of
    required Dojo core packages.

    -Adam


    2010/12/2 Tom Trenka <ttrenka at gmail.com <mailto:ttrenka at gmail.com>>

    I think the basic game plan (once 2.0 really starts taking shape)
    is to be able to collect a set of packages that we'd call "Dojo
    Toolkit 2.0", and gather them for a single release point that
    would be grabbed the same way distributions are downloaded
    now...so a set of packages of whatever we call "core", the set of
    packages that collectively make up Dijit, and selected (current)
    DojoX projects. The latter would be what we consider to be most
    important from a marketing standpoint (such as gfx and charting,
    should they remain separate github-maintained projects), and would
    serve as examples of how to "install" your own packages.

    Does that help?

    Regards--
    Tom


    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese <bill at dojotoolkit.org
    wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to
    "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js,
    https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also
    perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still
    be a
    single repository for dojo core (or if they are separate
    repositories,
    how will permissions work)? Will there still be a single
    dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download
    to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101202/24f6ef17/attachment-0001.htm
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 5199 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101202/24f6ef17/attachment-0001.p7s
  • Adam L. Peller at Dec 3, 2010 at 12:47 am
    Sasha,

    I'm certain that most of dojox really does not belong in the main release
    cycle, nevermind the potential for hundreds of user-written plugins which
    ought to be shared and advertised more easily. Keeping everything in a
    single release cycle prevents us from scaling up the number of projects and
    growing the community. The reality is that even within what we might
    consider our core set of work, not all open source developers are going to
    be able to work on the same schedule.

    While I think having a single monolithic release has been one of our biggest
    failings as a project -- our releases have been something of a farce with
    dojox code uniformly tagged whether it's tested or not, changed or not --
    you make a very important point that simplifying the release process, to the
    user, is a major advantage. Perhaps we can have it both ways from a
    federated system of sorts, where the plugins are maintained with a truly
    independent infrastructure, but a certain key set of projects or sets of
    projects maintained on the same release cycle as a matter of policy (and not
    as dictated by infrastructure). Rather than a single release or many tiny
    releases, perhaps it would make sense to release plugins in clusters? Or,
    perhaps the plugin releases could be independent, but larger compound,
    tested, versioned distributions could be created later, and that's what the
    end product would look like to most people?

    -Adam


    2010/12/2 Sasha Firsov <suns at firsov.net>
    Adam,
    In my past of corporate environment the presence of stable and sufficient
    feature set (including widgets) was one of key decision making points on
    selection which JS library to use.
    jQuery is suffering from the model you described. With zillions of plugins
    available, there is no chance to find enough basic ones matching core
    release. Dojo in that respect is quite more reliable. Having common release
    and life cycle for core, dijit and all dojoX is a major advantage.
    As far as I know there is a branch for experimental packages until they
    eventually will be promoted to dojoX and may be further.
    Making 3-rd party widgets/libraries listed and accessible over own
    registrar is a great idea, but not at cost of integrity of dojo as a whole.
    Just check how CSS thread goes over all branches. It has a perfect sense to
    keep them as solid entity.

    The independent development offered by git does not prevent to have stable
    release for whole toolkit and local/temporary branching for ongoing stuff. I
    guess everyone on thread is well aware of what distributed CMS (like git or
    mercurial) could offer.
    -Sasha


    On 12/2/2010 7:48 PM, Adam L. Peller wrote:

    I've got a more minimalist view, that we'd adopt the model where we have a
    small, stable core (dojo.js) not unlike jquery, and plugins from the
    community, each one we can choose to manage ourselves or let the community
    run as appropriate. We could choose to call the whole thing Dojo toolkit or
    some set profile, though I don't think we should try to package anything
    like what we have in DojoX today. Instead, tools (like the webbuilder tool
    James is working on) should make it easy to download and use what you need.
    Each DojoX subproject (no longer called DojoX) could be marketed and
    developed on its own, some with the Dojo seal of approval and some without,
    each free to do its own release cycle, marketing and maintenance. In this
    way, I would think Dijit would be packaged like any other subproject, but
    clearly one with a lot of importance. That wouldn't prevent someone from
    packaging certain useful profiles for download, but I would hope the Dojo
    toolkit would no longer be looked at as one big zip file. Dijit might very
    well be offered as a medium-size distribution with a set of required Dojo
    core packages.

    -Adam


    2010/12/2 Tom Trenka <ttrenka at gmail.com>
    I think the basic game plan (once 2.0 really starts taking shape) is to be
    able to collect a set of packages that we'd call "Dojo Toolkit 2.0", and
    gather them for a single release point that would be grabbed the same way
    distributions are downloaded now...so a set of packages of whatever we call
    "core", the set of packages that collectively make up Dijit, and selected
    (current) DojoX projects. The latter would be what we consider to be most
    important from a marketing standpoint (such as gfx and charting, should they
    remain separate github-maintained projects), and would serve as examples of
    how to "install" your own packages.

    Does that help?

    Regards--
    Tom

    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still be a
    single repository for dojo core (or if they are separate repositories,
    how will permissions work)? Will there still be a single dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing listdojo-contributors at mail.dojotoolkit.orghttp://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101203/5f92fb50/attachment-0001.htm
  • Dylan Schiemann at Dec 4, 2010 at 5:59 pm
    One of the key strengths people identify about Dojo is that "it has
    everything I need, of high quality, in one place".

    Hopefully with our new approach to structuring our extensions, use of
    things like RequireJS/CommonJS AMD, etc., and the work on the new Dojo
    Builder, we can make things easier to test and assemble, so that we
    offer the flexibility of independent modules, without losing the
    benefits and perception of a coherent simple way to get a release of the
    modules you need.

    Basically be the most modular, and be the best at offering a complete
    solution!

    Regards,
    - -Dylan
    Adam L. Peller December 2, 2010 10:47 PM:

    Sasha,

    I'm certain that most of dojox really does not belong in the main
    release cycle, nevermind the potential for hundreds of user-written
    plugins which ought to be shared and advertised more easily. Keeping
    everything in a single release cycle prevents us from scaling up the
    number of projects and growing the community. The reality is that even
    within what we might consider our core set of work, not all open source
    developers are going to be able to work on the same schedule.

    While I think having a single monolithic release has been one of our
    biggest failings as a project -- our releases have been something of a
    farce with dojox code uniformly tagged whether it's tested or not,
    changed or not -- you make a very important point that simplifying the
    release process, to the user, is a major advantage. Perhaps we can have
    it both ways from a federated system of sorts, where the plugins are
    maintained with a truly independent infrastructure, but a certain key
    set of projects or sets of projects maintained on the same release cycle
    as a matter of policy (and not as dictated by infrastructure). Rather
    than a single release or many tiny releases, perhaps it would make sense
    to release plugins in clusters? Or, perhaps the plugin releases could
    be independent, but larger compound, tested, versioned distributions
    could be created later, and that's what the end product would look like
    to most people?

    -Adam


    2010/12/2 Sasha Firsov <suns at firsov.net <mailto:suns at firsov.net>>

    Adam,
    In my past of corporate environment the presence of stable and
    sufficient feature set (including widgets) was one of key decision
    making points on selection which JS library to use.
    jQuery is suffering from the model you described. With zillions of
    plugins available, there is no chance to find enough basic ones
    matching core release. Dojo in that respect is quite more reliable.
    Having common release and life cycle for core, dijit and all dojoX
    is a major advantage.
    As far as I know there is a branch for experimental packages until
    they eventually will be promoted to dojoX and may be further.
    Making 3-rd party widgets/libraries listed and accessible over own
    registrar is a great idea, but not at cost of integrity of dojo as a
    whole.
    Just check how CSS thread goes over all branches. It has a perfect
    sense to keep them as solid entity.

    The independent development offered by git does not prevent to have
    stable release for whole toolkit and local/temporary branching for
    ongoing stuff. I guess everyone on thread is well aware of what
    distributed CMS (like git or mercurial) could offer.
    -Sasha

    On 12/2/2010 7:48 PM, Adam L. Peller wrote:
    I've got a more minimalist view, that we'd adopt the model
    where we have a small, stable core (dojo.js) not unlike jquery,
    and plugins from the community, each one we can choose to manage
    ourselves or let the community run as appropriate. We could
    choose to call the whole thing Dojo toolkit or some set profile,
    though I don't think we should try to package anything like what
    we have in DojoX today. Instead, tools (like the webbuilder tool
    James is working on) should make it easy to download and use what
    you need. Each DojoX subproject (no longer called DojoX) could be
    marketed and developed on its own, some with the Dojo seal of
    approval and some without, each free to do its own release cycle,
    marketing and maintenance. In this way, I would think Dijit would
    be packaged like any other subproject, but clearly one with a lot
    of importance. That wouldn't prevent someone from packaging
    certain useful profiles for download, but I would hope the Dojo
    toolkit would no longer be looked at as one big zip file. Dijit
    might very well be offered as a medium-size distribution with a
    set of required Dojo core packages.

    -Adam


    2010/12/2 Tom Trenka <ttrenka at gmail.com <mailto:ttrenka at gmail.com>>

    I think the basic game plan (once 2.0 really starts taking
    shape) is to be able to collect a set of packages that we'd
    call "Dojo Toolkit 2.0", and gather them for a single release
    point that would be grabbed the same way distributions are
    downloaded now...so a set of packages of whatever we call
    "core", the set of packages that collectively make up Dijit,
    and selected (current) DojoX projects. The latter would be
    what we consider to be most important from a marketing
    standpoint (such as gfx and charting, should they remain
    separate github-maintained projects), and would serve as
    examples of how to "install" your own packages.

    Does that help?

    Regards--
    Tom


    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese
    <bill at dojotoolkit.org wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects
    to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js,
    https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd.
    (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there
    still be a
    single repository for dojo core (or if they are separate
    repositories,
    how will permissions work)? Will there still be a single
    dojo core
    release? Will there still be something called "dojo
    toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to
    download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    ------------------------------------------------------------------------

    Sasha Firsov December 2, 2010 9:53 PM:

    Adam,
    In my past of corporate environment the presence of stable and
    sufficient feature set (including widgets) was one of key decision
    making points on selection which JS library to use.
    jQuery is suffering from the model you described. With zillions of
    plugins available, there is no chance to find enough basic ones matching
    core release. Dojo in that respect is quite more reliable. Having common
    release and life cycle for core, dijit and all dojoX is a major advantage.
    As far as I know there is a branch for experimental packages until they
    eventually will be promoted to dojoX and may be further.
    Making 3-rd party widgets/libraries listed and accessible over own
    registrar is a great idea, but not at cost of integrity of dojo as a whole.
    Just check how CSS thread goes over all branches. It has a perfect sense
    to keep them as solid entity.

    The independent development offered by git does not prevent to have
    stable release for whole toolkit and local/temporary branching for
    ongoing stuff. I guess everyone on thread is well aware of what
    distributed CMS (like git or mercurial) could offer.
    -Sasha
    On 12/2/2010 7:48 PM, Adam L. Peller wrote:
    I've got a more minimalist view, that we'd adopt the model where we
    have a small, stable core (dojo.js) not unlike jquery, and plugins
    from the community, each one we can choose to manage ourselves or let
    the community run as appropriate. We could choose to call the whole
    thing Dojo toolkit or some set profile, though I don't think we should
    try to package anything like what we have in DojoX today. Instead,
    tools (like the webbuilder tool James is working on) should make it
    easy to download and use what you need. Each DojoX subproject (no
    longer called DojoX) could be marketed and developed on its own, some
    with the Dojo seal of approval and some without, each free to do its
    own release cycle, marketing and maintenance. In this way, I would
    think Dijit would be packaged like any other subproject, but clearly
    one with a lot of importance. That wouldn't prevent someone from
    packaging certain useful profiles for download, but I would hope the
    Dojo toolkit would no longer be looked at as one big zip file. Dijit
    might very well be offered as a medium-size distribution with a set of
    required Dojo core packages.

    -Adam


    2010/12/2 Tom Trenka <ttrenka at gmail.com <mailto:ttrenka at gmail.com>>

    I think the basic game plan (once 2.0 really starts taking shape)
    is to be able to collect a set of packages that we'd call "Dojo
    Toolkit 2.0", and gather them for a single release point that
    would be grabbed the same way distributions are downloaded
    now...so a set of packages of whatever we call "core", the set of
    packages that collectively make up Dijit, and selected (current)
    DojoX projects. The latter would be what we consider to be most
    important from a marketing standpoint (such as gfx and charting,
    should they remain separate github-maintained projects), and would
    serve as examples of how to "install" your own packages.

    Does that help?

    Regards--
    Tom


    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese <bill at dojotoolkit.org
    wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to
    "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js,
    https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also
    perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still
    be a
    single repository for dojo core (or if they are separate
    repositories,
    how will permissions work)? Will there still be a single
    dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download
    to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    ------------------------------------------------------------------------

    Adam L. Peller December 2, 2010 8:48 PM:

    I've got a more minimalist view, that we'd adopt the model where we have
    a small, stable core (dojo.js) not unlike jquery, and plugins from the
    community, each one we can choose to manage ourselves or let the
    community run as appropriate. We could choose to call the whole thing
    Dojo toolkit or some set profile, though I don't think we should try to
    package anything like what we have in DojoX today. Instead, tools (like
    the webbuilder tool James is working on) should make it easy to download
    and use what you need. Each DojoX subproject (no longer called DojoX)
    could be marketed and developed on its own, some with the Dojo seal of
    approval and some without, each free to do its own release cycle,
    marketing and maintenance. In this way, I would think Dijit would be
    packaged like any other subproject, but clearly one with a lot of
    importance. That wouldn't prevent someone from packaging certain useful
    profiles for download, but I would hope the Dojo toolkit would no longer
    be looked at as one big zip file. Dijit might very well be offered as a
    medium-size distribution with a set of required Dojo core packages.

    -Adam


    2010/12/2 Tom Trenka <ttrenka at gmail.com <mailto:ttrenka at gmail.com>>

    I think the basic game plan (once 2.0 really starts taking shape) is
    to be able to collect a set of packages that we'd call "Dojo Toolkit
    2.0", and gather them for a single release point that would be
    grabbed the same way distributions are downloaded now...so a set of
    packages of whatever we call "core", the set of packages that
    collectively make up Dijit, and selected (current) DojoX projects.
    The latter would be what we consider to be most important from a
    marketing standpoint (such as gfx and charting, should they remain
    separate github-maintained projects), and would serve as examples of
    how to "install" your own packages.

    Does that help?

    Regards--
    Tom


    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese <bill at dojotoolkit.org
    wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to "be
    part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js,
    https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still be a
    single repository for dojo core (or if they are separate
    repositories,
    how will permissions work)? Will there still be a single dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    ------------------------------------------------------------------------

    Tom Trenka December 2, 2010 7:23 PM:

    I think the basic game plan (once 2.0 really starts taking shape) is to
    be able to collect a set of packages that we'd call "Dojo Toolkit 2.0",
    and gather them for a single release point that would be grabbed the
    same way distributions are downloaded now...so a set of packages of
    whatever we call "core", the set of packages that collectively make up
    Dijit, and selected (current) DojoX projects. The latter would be what
    we consider to be most important from a marketing standpoint (such as
    gfx and charting, should they remain separate github-maintained
    projects), and would serve as examples of how to "install" your own
    packages.

    Does that help?

    Regards--
    Tom

    On Thu, Dec 2, 2010 at 7:46 PM, Bill Keese <bill at dojotoolkit.org
    wrote:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still be a
    single repository for dojo core (or if they are separate repositories,
    how will permissions work)? Will there still be a single dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    ------------------------------------------------------------------------

    Bill Keese December 2, 2010 6:46 PM:

    Nowadays many people in the dojo community is making their own
    projects in github. We plan for many of those projects to "be part
    of dojo 2.0": https://github.com/jrburke/requirejs,
    https://github.com/phiggins42/has.js, https://github.com/uhop/pulsar,
    maybe parts of https://github.com/phiggins42/plugd. (Also perhaps
    https://github.com/phiggins42/mustache.js,
    https://github.com/kriszyp/compose,
    https://github.com/kriszyp/objectable,
    https://github.com/dmachi/virtual-datalist, ...)

    I'm just wondering, how will this all work? Will there still be a
    single repository for dojo core (or if they are separate repositories,
    how will permissions work)? Will there still be a single dojo core
    release? Will there still be something called "dojo toolkit" at
    least from a marketing angle?

    I know that we plan to release the dojox projects as separate
    packages, but how many packages will people need to download to get
    (what today we call) dojo core?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Sam foster at Dec 8, 2010 at 5:11 am
    There's a real danger of throwing the baby out w. the bath water here.
    To be clear, jQuery's plugin ecosystem is simultaneously one of its
    strengths and failings. Determining quality and compatibility seems to
    come down to knowing the reputation of the author. Aping that is a big
    step backwards for dojo. We need to encourage the growth of the dojo
    ecosystem without losing the "toolkit" bit of dojo.

    In the wild, the way we manage external dependencies typically goes
    one of 2 ways:

    1) Link them in (e.g. svn:external) and keep them discrete and clearly 3rd party
    2) Import and adopt them into your own codebase by re-namespacing and
    taking ownership of the snapshot you use (while still preserving
    attribution)

    The same can be true for the toolkit. E.g. RequireJs can continue to
    exist as a toolkit-independent utility, but dojo can embed and adopt
    it as a loader. Part of our release process will be to bring over any
    patches. On the flip side authors and organizations should be able to
    maintain their code outside the toolkit (using potentially different
    licenses if necessary). We just need a package system (like node's
    npm?) with some metadata indicating the version compatibility,
    license, namespaces, and to host that somewhere people can find it.

    dojox doesn't need to go away, but perhaps we change the default so
    that dojox code is excluded from a release unless it is explicitly
    tested and compatibility, docs etc confirmed at each release?

    On Sat, Dec 4, 2010 at 10:59 PM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    One of the key strengths people identify about Dojo is that "it has
    everything I need, of high quality, in one place".

    Hopefully with our new approach to structuring our extensions, use of
    things like RequireJS/CommonJS AMD, etc., and the work on the new Dojo
    Builder, we can make things easier to test and assemble, so that we
    offer the flexibility of independent modules, without losing the
    benefits and perception of a coherent simple way to get a release of the
    modules you need.

    Basically be the most modular, and be the best at offering a complete
    solution!
    (way to top-post dylan :)
  • Sasha Firsov at Dec 8, 2010 at 11:35 am
    It seems as a storm in a glass of water. We are going to adopt GIT(?).
    What prevent us to get complete release model of Linux than?
    There are quite a bit of articles and books on subject. It fits to brief
    Sam's description.
    Release includes as kernel as third-party apps. Each with independent
    life. Once in a while during release process, stable release of package
    is choosen and tested for compatibility. Not necessary last one. And so
    on...
    ... pick one of guidelines and follow?

    -S
    On 12/8/2010 2:11 AM, sam foster wrote:
    There's a real danger of throwing the baby out w. the bath water here.
    To be clear, jQuery's plugin ecosystem is simultaneously one of its
    strengths and failings. Determining quality and compatibility seems to
    come down to knowing the reputation of the author. Aping that is a big
    step backwards for dojo. We need to encourage the growth of the dojo
    ecosystem without losing the "toolkit" bit of dojo.

    In the wild, the way we manage external dependencies typically goes
    one of 2 ways:

    1) Link them in (e.g. svn:external) and keep them discrete and clearly 3rd party
    2) Import and adopt them into your own codebase by re-namespacing and
    taking ownership of the snapshot you use (while still preserving
    attribution)

    The same can be true for the toolkit. E.g. RequireJs can continue to
    exist as a toolkit-independent utility, but dojo can embed and adopt
    it as a loader. Part of our release process will be to bring over any
    patches. On the flip side authors and organizations should be able to
    maintain their code outside the toolkit (using potentially different
    licenses if necessary). We just need a package system (like node's
    npm?) with some metadata indicating the version compatibility,
    license, namespaces, and to host that somewhere people can find it.

    dojox doesn't need to go away, but perhaps we change the default so
    that dojox code is excluded from a release unless it is explicitly
    tested and compatibility, docs etc confirmed at each release?


    On Sat, Dec 4, 2010 at 10:59 PM, Dylan Schiemannwrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    One of the key strengths people identify about Dojo is that "it has
    everything I need, of high quality, in one place".

    Hopefully with our new approach to structuring our extensions, use of
    things like RequireJS/CommonJS AMD, etc., and the work on the new Dojo
    Builder, we can make things easier to test and assemble, so that we
    offer the flexibility of independent modules, without losing the
    benefits and perception of a coherent simple way to get a release of the
    modules you need.

    Basically be the most modular, and be the best at offering a complete
    solution!
    (way to top-post dylan :)
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 5199 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101208/77d8c5c4/attachment.p7s
  • Adam L. Peller at Dec 8, 2010 at 12:44 pm

    On Wed, Dec 8, 2010 at 5:11 AM, sam foster wrote:

    There's a real danger of throwing the baby out w. the bath water here.
    To be clear, jQuery's plugin ecosystem is simultaneously one of its
    strengths and failings. Determining quality and compatibility seems to
    come down to knowing the reputation of the author. Aping that is a big
    step backwards for dojo. We need to encourage the growth of the dojo
    ecosystem without losing the "toolkit" bit of dojo.
    Right. Let's capitalize on the strengths (scalability) and do better wrt
    weaknesses (provide tools and metadata) No reason why we should have it
    both ways. With proper tools and metadata, we can reconstruct distributions
    which reflect what we have now (some core, supported "toolkit") if we really
    wanted to, but I'd rather see different parts of Dojo develop their own
    brand and community. That doesn't mean every plugin must be treated as a
    separate entity like jquery. My guess is that we would want to tune
    today's toolkit distribution a good amount, or even provide a small number
    of options in place of a one-size-fits-nobody download, then let the
    community provide what it wants to, with appropriate ratings and
    documentation.

    In the wild, the way we manage external dependencies typically goes
    one of 2 ways:

    1) Link them in (e.g. svn:external) and keep them discrete and clearly 3rd
    party
    2) Import and adopt them into your own codebase by re-namespacing and
    taking ownership of the snapshot you use (while still preserving
    attribution)
    what if we had tools to do all this?

    The same can be true for the toolkit. E.g. RequireJs can continue to
    exist as a toolkit-independent utility, but dojo can embed and adopt
    it as a loader.

    requirejs seems a bit special. I'm still a bit confused on our strategy for
    providing new? alternative? loaders in the 1.6-2.0 timeframe.

    Part of our release process will be to bring over any
    patches. On the flip side authors and organizations should be able to
    maintain their code outside the toolkit (using potentially different
    licenses if necessary). We just need a package system (like node's
    npm?) with some metadata indicating the version compatibility,
    license, namespaces, and to host that somewhere people can find it.
    any idea how node npm compares with http://wiki.commonjs.org/wiki/Packages ?

    dojox doesn't need to go away, but perhaps we change the default so
    that dojox code is excluded from a release unless it is explicitly
    tested and compatibility, docs etc confirmed at each release?
    dojox was really nothing more than a temporary way for us to start building
    new projects on dojo. As a unit, it never made any sense. As pieces, each
    ought to be considered on its own merit.

    -Adam

    On Sat, Dec 4, 2010 at 10:59 PM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    One of the key strengths people identify about Dojo is that "it has
    everything I need, of high quality, in one place".

    Hopefully with our new approach to structuring our extensions, use of
    things like RequireJS/CommonJS AMD, etc., and the work on the new Dojo
    Builder, we can make things easier to test and assemble, so that we
    offer the flexibility of independent modules, without losing the
    benefits and perception of a coherent simple way to get a release of the
    modules you need.

    Basically be the most modular, and be the best at offering a complete
    solution!
    (way to top-post dylan :)
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101208/1ad3b482/attachment.htm
  • Kris Zyp at Dec 8, 2010 at 1:58 pm

    On 12/8/2010 10:44 AM, Adam L. Peller wrote:

    On Wed, Dec 8, 2010 at 5:11 AM, sam foster <potatosculptor at gmail.com
    wrote:

    There's a real danger of throwing the baby out w. the bath water here.
    To be clear, jQuery's plugin ecosystem is simultaneously one of its
    strengths and failings. Determining quality and compatibility seems to
    come down to knowing the reputation of the author. Aping that is a big
    step backwards for dojo. We need to encourage the growth of the dojo
    ecosystem without losing the "toolkit" bit of dojo.


    Right. Let's capitalize on the strengths (scalability) and do better
    wrt weaknesses (provide tools and metadata) No reason why we should
    have it both ways. With proper tools and metadata, we can reconstruct
    distributions which reflect what we have now (some core, supported
    "toolkit") if we really wanted to, but I'd rather see different parts
    of Dojo develop their own brand and community. That doesn't mean
    every plugin must be treated as a separate entity like jquery. My
    guess is that we would want to tune today's toolkit distribution a
    good amount, or even provide a small number of options in place of a
    one-size-fits-nobody download, then let the community provide what it
    wants to, with appropriate ratings and documentation.


    In the wild, the way we manage external dependencies typically goes
    one of 2 ways:

    1) Link them in (e.g. svn:external) and keep them discrete and
    clearly 3rd party
    2) Import and adopt them into your own codebase by re-namespacing and
    taking ownership of the snapshot you use (while still preserving
    attribution)


    what if we had tools to do all this?
    Working on it [1][2].

    The same can be true for the toolkit. E.g. RequireJs can continue to
    exist as a toolkit-independent utility, but dojo can embed and adopt
    it as a loader.


    requirejs seems a bit special. I'm still a bit confused on our
    strategy for providing new? alternative? loaders in the 1.6-2.0 timeframe.
    Ben Hockey got Dojo 1.6 working on RequireJS, and Rawld is wrapping up
    the backdraft loader, which presumably we can include in Dojo 1.7.

    Part of our release process will be to bring over any
    patches. On the flip side authors and organizations should be able to
    maintain their code outside the toolkit (using potentially different
    licenses if necessary). We just need a package system (like node's
    npm?) with some metadata indicating the version compatibility,
    license, namespaces, and to host that somewhere people can find it.


    any idea how node npm compares
    with http://wiki.commonjs.org/wiki/Packages ?
    NPM follows it closely, and also
    http://wiki.commonjs.org/wiki/Packages/Registrywhich defines how the
    package manager interacts with the package registry. I have been
    following the spec and working with Isaac (the author of NPM and the
    spec) to ensure that we have compatibility between NPM and our package
    registry [1] I have been working on and package manager/installer [2].
    This should make it possible to install packages from our repository
    into Node with NPM, and to install packages from NPM's registry into
    Dojo apps.

    [1] http://packages.dojofoundation.org/
    [2] http://github.com/kriszyp/cpm

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101208/4bc0690d/attachment-0001.htm
  • Adam L. Peller at Dec 8, 2010 at 2:38 pm
    inline...
    On Wed, Dec 8, 2010 at 1:58 PM, Kris Zyp wrote:

    1) Link them in (e.g. svn:external) and keep them discrete and clearly 3rd
    party
    2) Import and adopt them into your own codebase by re-namespacing and
    taking ownership of the snapshot you use (while still preserving
    attribution)

    what if we had tools to do all this?
    Working on it [1][2].
    svn:externals distributes the code, but doesn't it lead us back to one huge
    logical repository, just stored in different places? I think our real
    problem is that we need a decentralized model. If we want to grow, we can't
    control everything, nor should we try to.

    requirejs seems a bit special. I'm still a bit confused on our strategy for
    providing new? alternative? loaders in the 1.6-2.0 timeframe.


    Ben Hockey got Dojo 1.6 working on RequireJS, and Rawld is wrapping up the
    backdraft loader, which presumably we can include in Dojo 1.7.

    Right. What I meant was packaging. Are we packaging either loader with
    Dojo, or are they going to be available only as separate downloads?

    any idea how node npm compares with http://wiki.commonjs.org/wiki/Packages?

    NPM follows it closely, and also
    http://wiki.commonjs.org/wiki/Packages/Registry which defines how the
    package manager interacts with the package registry. I have been following
    the spec and working with Isaac (the author of NPM and the spec) to ensure
    that we have compatibility between NPM and our package registry [1] I have
    been working on and package manager/installer [2]. This should make it
    possible to install packages from our repository into Node with NPM, and to
    install packages from NPM's registry into Dojo apps.

    Fantastic!
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101208/fa8f9bf1/attachment-0001.htm
  • Kris Zyp at Dec 8, 2010 at 2:45 pm

    On 12/8/2010 12:38 PM, Adam L. Peller wrote:
    inline...

    On Wed, Dec 8, 2010 at 1:58 PM, Kris Zyp <kzyp at dojotoolkit.org
    wrote:
    1) Link them in (e.g. svn:external) and keep them discrete
    and clearly 3rd party
    2) Import and adopt them into your own codebase by
    re-namespacing and
    taking ownership of the snapshot you use (while still preserving
    attribution)

    what if we had tools to do all this?
    Working on it [1][2].


    svn:externals distributes the code, but doesn't it lead us back to one
    huge logical repository, just stored in different places? I think our
    real problem is that we need a decentralized model. If we want to
    grow, we can't control everything, nor should we try to.
    I am not sure I understand, [1][2] were references to the projects
    below, not svn:externals. Or are you saying that maintaining a
    repository is undesirable? The package installer can be point to any
    repository, including NPM's (the code for repository I am working is at
    http://github.com/kriszyp/cpr), so everything can be decentralized.
    requirejs seems a bit special. I'm still a bit confused on our
    strategy for providing new? alternative? loaders in the 1.6-2.0
    timeframe.
    Ben Hockey got Dojo 1.6 working on RequireJS, and Rawld is
    wrapping up the backdraft loader, which presumably we can include
    in Dojo 1.7.

    Right. What I meant was packaging. Are we packaging either loader
    with Dojo, or are they going to be available only as separate downloads?
    By "include in Dojo 1.7", I meant packaged in Dojo 1.7... As in,
    included in the same download... Not in a separate download... :).
    any idea how node npm compares
    with http://wiki.commonjs.org/wiki/Packages ?
    NPM follows it closely, and also
    http://wiki.commonjs.org/wiki/Packages/Registrywhich defines how
    the package manager interacts with the package registry. I have
    been following the spec and working with Isaac (the author of NPM
    and the spec) to ensure that we have compatibility between NPM and
    our package registry [1] I have been working on and package
    manager/installer [2]. This should make it possible to install
    packages from our repository into Node with NPM, and to install
    packages from NPM's registry into Dojo apps.

    Fantastic!
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101208/d5db33b1/attachment.htm
  • Adam L. Peller at Dec 8, 2010 at 2:48 pm

    On Wed, Dec 8, 2010 at 2:45 PM, Kris Zyp wrote:
    I am not sure I understand, [1][2] were references to the projects below,
    not svn:externals.

    Oops. Confused ] for ). Nevermind!

    -Adam
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101208/6654ea9f/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedDec 2, '10 at 8:46p
activeDec 8, '10 at 2:48p
posts18
users8
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase