seems like we need to shape up the road map for 1.4, 1.5, 2.0 and
anything in between. From the #dojo-meeting, I heard the following
thoughts:

* (jamestag) core: better productivity in core, part of that relates
to making sure we have a story or at least a doc mapping how base+core
can be used like jquery. perf optimizations where they make sense. i
wanted those things in 1.4/1.5, for 2.0 i want to take that time to
trim things out of base that are not commonly needed, like the withDoc
stuff, get rid of things i think are redundant. take the moment to
break the api, but i think we can

* (ttrenka) breaking DojoX away from the DTK release

* (sfoster) I'd like to see dojoc grow into the community sandbox.

The roadmap needs impetus, and an owner, and eventually consensus so
we can all get behind it and push. This is critical for all the
companies betting on dojo, and a good thing to have as guidance as we
triage tickets, add features, and contemplate work on infrastructure,
tools, and so on.

What will the tagline be for 1.4? for 1.5? And what, apart from a
general cleanout will 2.0 be all about in your mind? Please add your
thoughts and any plans you have, or are aware of.

Sam

Search Discussions

  • Mike Wilcox at May 7, 2009 at 8:58 pm
    The IBM Team is doing their work on the DataChart, DataGrid, easier
    Dijit Syling, Themes, etc. This is a very positive thing that should
    be included in the roadmap.

    What I'd like to see on the Roadmap:

    Better Build Tools
    Dustin I know is working on something that should help.
    The AIR Toolbox Builder is a good start, but fell short of actually
    helping newbies. It would be awesome if updates for that could get
    funded.

    Better CSS
    The IBM team is working on making Dijits easier to style (I hope that
    works!)
    Help is needed on what style sheets are to be included in a Dojo app.
    Even some CSS-specific help docs or something.
    No more body class="tundra". Ugh. Why isn't that the default?

    Dojo Core vs Dojo Base
    Dojo Base should be "Dojo". Dojo Core should be... something else.
    Dojo Plus maybe. PlusD? Heh.

    Dojox -> Plugins
    I don't know what the status of breaking Dojox into a set of plugins
    is, but it's very important from a new dev perspective. This idea
    seems to be suffering from paralysis by analysis.

    Unofficial plugins promoted
    I think this helps JQ get buzz, because anyone can write a plugin.
    This is more marketing, but I figured while I was at it...

    Dojo Data Refactor
    The stores need to be reigned in; they're getting too idiosyncratic.
    Each of them uses a different API. It's murder switching between
    stores because you have to learn an entirely new query language (and
    they are not documented). Data Stores are really catching on and we
    need to make them easier to use.

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On May 6, 2009, at 5:43 PM, sam foster wrote:

    seems like we need to shape up the road map for 1.4, 1.5, 2.0 and
    anything in between. From the #dojo-meeting, I heard the following
    thoughts:

    * (jamestag) core: better productivity in core, part of that relates
    to making sure we have a story or at least a doc mapping how base+core
    can be used like jquery. perf optimizations where they make sense. i
    wanted those things in 1.4/1.5, for 2.0 i want to take that time to
    trim things out of base that are not commonly needed, like the withDoc
    stuff, get rid of things i think are redundant. take the moment to
    break the api, but i think we can

    * (ttrenka) breaking DojoX away from the DTK release

    * (sfoster) I'd like to see dojoc grow into the community sandbox.

    The roadmap needs impetus, and an owner, and eventually consensus so
    we can all get behind it and push. This is critical for all the
    companies betting on dojo, and a good thing to have as guidance as we
    triage tickets, add features, and contemplate work on infrastructure,
    tools, and so on.

    What will the tagline be for 1.4? for 1.5? And what, apart from a
    general cleanout will 2.0 be all about in your mind? Please add your
    thoughts and any plans you have, or are aware of.

    Sam
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Mike Wilcox at May 7, 2009 at 9:04 pm
    I'd like to propose that dijit.sniff get promoted to Dojo Base.

    In case you're not familiar, this is the code that assigns the class
    to the html tag, like dj_ie, dj_ie, dj_webkit, etc.

    This is a fantastic feature that really gets designers excited when
    they hear about it. It would be nice to promote Dojo Base as a little
    library that can be dropped into your website and give you this
    feature. It's unique (afaik).

    I mentioned it on Ajaxian a few days ago as an alternative to the
    crazy CSS hacks that designers have to do. It seemed to catch some
    commenters by surprise.

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
  • Peter E Higgins at May 8, 2009 at 1:07 am

    Mike Wilcox wrote:
    I'd like to propose that dijit.sniff get promoted to Dojo Base.
    we can't really afford it [the bytes] in base, but the functionality is
    already slated for Core. I'd hoped to do it for 1.3, but slacked.
    Moving parts of dijit.place into Dojo Core was also part of this.

    Regards,
    Peter


    --
    Peter E Higgins
    Dojo Project Lead : http://dojotoolkit.org
  • Adam Peller at May 8, 2009 at 12:36 pm
    I'm ok with it moving to core as a module that people can optionally
    use. It's often a necessary evil, but many people believe user-agent
    sniffing is a bad practice or a last resort, and it's certainly not
    future-proof, so I'd be -1 on base, regardless of code size.

    -Adam
    On Fri, May 8, 2009 at 1:07 AM, Peter E Higgins wrote:
    Mike Wilcox wrote:
    I'd like to propose that dijit.sniff get promoted to Dojo Base.
    we can't really afford it [the bytes] in base, but the functionality is
    already slated for Core. ?I'd hoped to do it for 1.3, but slacked.
    Moving parts of dijit.place into Dojo Core was also part of this.

    Regards,
    Peter


    --
    Peter E Higgins
    Dojo Project Lead : http://dojotoolkit.org

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Tom Trenka at May 8, 2009 at 1:21 pm
    This was actually a bit of a battle in the shift from 0.4 to 0.9. The issue
    at hand is that it's invasive on a document; having CSS classes added to a
    document simply because you load up Dojo is a bad thing from a marketing
    perspective, because any web developer (the kind of people using MooTools
    and jQuery) would like to have control over how their documents are
    manipulated.
    I'd be fine with it in the Core but I would definitely object to having it
    in Base; it should be an optional thing, not something we enforce on the
    community at large.

    regards,
    trt
    On Fri, May 8, 2009 at 11:36 AM, Adam Peller wrote:

    I'm ok with it moving to core as a module that people can optionally
    use. It's often a necessary evil, but many people believe user-agent
    sniffing is a bad practice or a last resort, and it's certainly not
    future-proof, so I'd be -1 on base, regardless of code size.

    -Adam
    On Fri, May 8, 2009 at 1:07 AM, Peter E Higgins wrote:
    Mike Wilcox wrote:
    I'd like to propose that dijit.sniff get promoted to Dojo Base.
    we can't really afford it [the bytes] in base, but the functionality is
    already slated for Core. I'd hoped to do it for 1.3, but slacked.
    Moving parts of dijit.place into Dojo Core was also part of this.

    Regards,
    Peter


    --
    Peter E Higgins
    Dojo Project Lead : http://dojotoolkit.org

    _______________________________________________
    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/20090508/5450bb6c/attachment.html
  • Revin Guillen at May 8, 2009 at 1:42 pm
    +1 for Core. It's useful enough to stand on its own rather than being
    hidden in dijit._base.sniff.

    I'm still of the opinion that people would understand Dojo better if
    we marketed it as a small fast core plus plugins, and the sniff is
    absolutely tiny--most of the real work is already being done in Base.
    It'd be a no-brainer addition to the Dojo version of the kind of blog
    posts you see all the time ("10 awesome jQuery pluginz!").

    --
    Revin Guillen
    SitePen, Inc.
    revin at sitepen.com
    (650) 968-8787 x210
    http://sitepen.com/




    On May 8, 2009, at May 8 | 10:21 AM, Tom Trenka wrote:

    This was actually a bit of a battle in the shift from 0.4 to 0.9.
    The issue at hand is that it's invasive on a document; having CSS
    classes added to a document simply because you load up Dojo is a bad
    thing from a marketing perspective, because any web developer (the
    kind of people using MooTools and jQuery) would like to have control
    over how their documents are manipulated.

    I'd be fine with it in the Core but I would definitely object to
    having it in Base; it should be an optional thing, not something we
    enforce on the community at large.

    regards,
    trt

    On Fri, May 8, 2009 at 11:36 AM, Adam Peller wrote:
    I'm ok with it moving to core as a module that people can optionally
    use. It's often a necessary evil, but many people believe user-agent
    sniffing is a bad practice or a last resort, and it's certainly not
    future-proof, so I'd be -1 on base, regardless of code size.

    -Adam

    On Fri, May 8, 2009 at 1:07 AM, Peter E Higgins
    wrote:
    Mike Wilcox wrote:
    I'd like to propose that dijit.sniff get promoted to Dojo Base.
    we can't really afford it [the bytes] in base, but the
    functionality is
    already slated for Core. I'd hoped to do it for 1.3, but slacked.
    Moving parts of dijit.place into Dojo Core was also part of this.

    Regards,
    Peter


    --
    Peter E Higgins
    Dojo Project Lead : http://dojotoolkit.org

    _______________________________________________
    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
  • Alex Russell at May 8, 2009 at 1:29 pm
    +1
    On Thu, May 7, 2009 at 6:04 PM, Mike Wilcox wrote:
    I'd like to propose that dijit.sniff get promoted to Dojo Base.

    In case you're not familiar, this is the code that assigns the class
    to the html tag, like dj_ie, dj_ie, dj_webkit, etc.

    This is a fantastic feature that really gets designers excited when
    they hear about it. It would be nice to promote Dojo Base as a little
    library that can be dropped into your website and give you this
    feature. It's unique (afaik).

    I mentioned it on Ajaxian a few days ago as an alternative to the
    crazy CSS hacks that designers have to do. It seemed to catch some
    commenters by surprise.

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: ? ? 214.697.4872
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at May 11, 2009 at 12:15 am
    Hi Sam,

    I don't have anything new to add since the last time we talked about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
  • Tom Trenka at May 14, 2009 at 11:28 am
    I've been kicking around some ideas, and I think at this point I'd like to
    promote what many of you might consider to be radical changes. Please bear
    with me on this and recognize that what I'm proposing here is meant to begin
    some real discussions...right now, I would be considering this proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release. Probably
    most would rather consider it for 2.0 but since our release cycles tend to
    be pushed way out, I think it's reasonable to consider this for an earlier
    major milestone...
    1.5: *Promote DojoX to be a true first-class citizen in the Dojosphere*.
    This may seem like an odd thing to say, but allow me to explain. Currently,
    DojoX is used for all sorts of different purposes--for some things, it's a
    breeding ground for eventual migration; for some, it's a playground; for
    others, it's like a personal repo.

    I would like this to change.

    The goal here would be to couple DojoX releases with the Core (and not
    Dijit, I'll get to that), so that the two projects are considered congruent.
    This means that the idea of trying to package individual projects in DojoX
    is no longer a necessity.

    In order for this to happen, I think we need to make the following changes,
    both directly to DojoX and also in the rules overseeing DojoX:

    *1. Migrate the pieces in DojoX that should be migrated.*
    On my list of things here, the following should be migrated to Core: gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit with all
    possible speed.

    *2. Make decisions on what current parts of DojoX should remain, as worthy
    parts of a core release.*
    The criteria here is that whatever remains needs to have the following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a semi-regular
    basis.
    c. having a focus that is part of the long term goals of the toolkit itself.
    d. is and continues to be under active development, if not entirely stable.

    On my short list here is FX, the Charting package, and (at least) Cometd.
    What else ends up on this list is entirely up to discussion but I would
    like to keep it short and solid; for example, I would consider Storage to be
    a candidate but I'm not sure about off, etc.

    *3. Move everything else out of DojoX and out of the release cycle.*
    Before anyone starts saying "hey, what the hell", hear me out.

    There are a lot of things sitting in DojoX currently that have only one
    developer, is not under active development, serves only a single party's
    needs, etc. etc. Most of these projects, while some are very interesting,
    should really not be a part of a Dojo release cycle at all (and I think this
    is one of the reasons why we've been going back and forth on the whole
    separate package thing), and so I think we should be moving them out of
    DojoX altogether. Things on this list (IMHO) include analytics, av, wires,
    sketch, collections, encoding, and more.

    However, I don't think we should be losing any of these projects either,
    so...

    *4. Take over the dojoc concept and rename it to something like "dplug",
    "plug" or "plugins".*
    But I'm going to simplify this idea (after talking it over with Dustin);
    what we basically do is this:

    a. allow anyone with current ownership of a DojoX project to choose how
    they would like to maintain the code (i.e. whether they want to move to a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would be what is
    currently the dojoc concept, but renamed to something like the above.
    c. With every Dojo release, provide an empty directory at the same level as
    dojo, dijit and dojox--named the above.

    The idea here is to allow *anyone* to use that namespace as an automatic way
    of being able to drop plugins into an existing Dojo release, not have to
    worry about registering a namespace, and being able to instantly go with
    whatever code they want. It'd also allow us to maintain a place where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release cycle.

    It should also allow whoever to be able to do builds without a huge amount
    of extra pain.
    -----------------

    There are a few things that I have deliberately left out of this--the
    biggest one being anything that is currently in DojoX that is widget-based.
    I have a proposal for this as well but I am unsure if it's the right way to
    go; however, I do feel that DojoX is no longer a place that widgets should
    be in and it should be congruent to Core and only Core.

    To this end, I might suggest *creating a DijitX project*--which would serve
    the same purpose for Dijit as DojoX does for Core. Anything widget-based
    that the Dijit team feels is a good add-on to Dijit without having to
    satisfy the same stringent requirements can go in there.

    In my mind though, the main thing is that anything in the streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------

    While aggressive, I think that this kind of change is definitely do-able for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub files in
    DojoX with deprecation messages for existing users, and make sure that users
    of that codebase can find the new locations of their project dependency.

    I'm proposing this idea because it seems to me like it kills several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that writing
    them is a simple matter of saying "call it plugin.foo and drop it in here".
    6. The build system can pick up plugins by adding a couple of lines to a
    specific profile (iirc).

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

    Thoughts, arguments, suggestions?

    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese wrote:

    Hi Sam,

    I don't have anything new to add since the last time we talked about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
    _______________________________________________
    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/20090514/eb169a1e/attachment.htm
  • Mike Wilcox at May 14, 2009 at 12:18 pm
    +1

    I like the DijitX idea. It fills out the plan nicely. Now we can start
    think of the 'X' to mean 'extension', and not 'experimental'.

    Suggested additions to Tom's list for promotion to Dojo: validation
    and json stuff. DropDownSelect should be promoted to Dijit if it's
    ready.

    One of the reasons I like the plugin concept is because currently
    there's no criteria to determine the popularity or usefulness of...
    well anything in Dojo. Having plugins allows for download tracking and
    a rating vote.

    I think there should definitely be an official plugin location for
    previous DojoX work, and stuff that has a CLA. Seems that the
    requirements for submission would be fairly light. Then an unofficial
    plugin location for non-cla work.

    I feel I have to vote against Adam's suggestion that plugins be what
    are currently packages in DojoX. I think each file should be a plugin,
    except for cases where they are a package in themselves (like lang for
    example).

    Namespace for a plugin? dojop? Should there be a dijitp?

    dojo, dijit, dojox, dijitx, dojop (dijitp)

    Mike Wilcox

    On May 14, 2009, at 10:28 AM, Tom Trenka wrote:

    I've been kicking around some ideas, and I think at this point I'd
    like to promote what many of you might consider to be radical
    changes. Please bear with me on this and recognize that what I'm
    proposing here is meant to begin some real discussions...right now,
    I would be considering this proposal as a (fairly) major
    reorganization aimed at the 1.5 milestone release. Probably most
    would rather consider it for 2.0 but since our release cycles tend
    to be pushed way out, I think it's reasonable to consider this for
    an earlier major milestone...

    1.5: Promote DojoX to be a true first-class citizen in the Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently, DojoX is used for all sorts of different purposes--for
    some things, it's a breeding ground for eventual migration; for
    some, it's a playground; for others, it's like a personal repo.

    I would like this to change.

    The goal here would be to couple DojoX releases with the Core (and
    not Dijit, I'll get to that), so that the two projects are
    considered congruent. This means that the idea of trying to package
    individual projects in DojoX is no longer a necessity.

    In order for this to happen, I think we need to make the following
    changes, both directly to DojoX and also in the rules overseeing
    DojoX:

    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: gfx, dtl, portions of io, rpc and data; grid should be
    migrated to Dijit with all possible speed.

    2. Make decisions on what current parts of DojoX should remain, as
    worthy parts of a core release.
    The criteria here is that whatever remains needs to have the
    following attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a semi-
    regular basis.
    c. having a focus that is part of the long term goals of the toolkit
    itself.
    d. is and continues to be under active development, if not entirely
    stable.

    On my short list here is FX, the Charting package, and (at least)
    Cometd. What else ends up on this list is entirely up to discussion
    but I would like to keep it short and solid; for example, I would
    consider Storage to be a candidate but I'm not sure about off, etc.

    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.

    There are a lot of things sitting in DojoX currently that have only
    one developer, is not under active development, serves only a single
    party's needs, etc. etc. Most of these projects, while some are
    very interesting, should really not be a part of a Dojo release
    cycle at all (and I think this is one of the reasons why we've been
    going back and forth on the whole separate package thing), and so I
    think we should be moving them out of DojoX altogether. Things on
    this list (IMHO) include analytics, av, wires, sketch, collections,
    encoding, and more.

    However, I don't think we should be losing any of these projects
    either, so...

    4. Take over the dojoc concept and rename it to something like
    "dplug", "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin); what we basically do is this:

    a. allow anyone with current ownership of a DojoX project to choose
    how they would like to maintain the code (i.e. whether they want to
    move to a different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would be
    what is currently the dojoc concept, but renamed to something like
    the above.
    c. With every Dojo release, provide an empty directory at the same
    level as dojo, dijit and dojox--named the above.

    The idea here is to allow *anyone* to use that namespace as an
    automatic way of being able to drop plugins into an existing Dojo
    release, not have to worry about registering a namespace, and being
    able to instantly go with whatever code they want. It'd also allow
    us to maintain a place where projects that have lived under DojoX
    for a while can undergo active development (if so desired) without
    having to be tied to a release cycle.

    It should also allow whoever to be able to do builds without a huge
    amount of extra pain.
    -----------------

    There are a few things that I have deliberately left out of this--
    the biggest one being anything that is currently in DojoX that is
    widget-based. I have a proposal for this as well but I am unsure if
    it's the right way to go; however, I do feel that DojoX is no longer
    a place that widgets should be in and it should be congruent to Core
    and only Core.

    To this end, I might suggest creating a DijitX project--which would
    serve the same purpose for Dijit as DojoX does for Core. Anything
    widget-based that the Dijit team feels is a good add-on to Dijit
    without having to satisfy the same stringent requirements can go in
    there.

    In my mind though, the main thing is that anything in the
    streamlined DojoX doesn't have or wrap any of the Dijit
    infrastructure.
    -----------------

    While aggressive, I think that this kind of change is definitely do-
    able for the 1.5 release (since it should not radically affect the
    other two projects); for backwards-compatibility, we can include
    simple stub files in DojoX with deprecation messages for existing
    users, and make sure that users of that codebase can find the new
    locations of their project dependency.

    I'm proposing this idea because it seems to me like it kills several
    birds with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as essential
    to the continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing them is a simple matter of saying "call it plugin.foo and
    drop it in here".
    6. The build system can pick up plugins by adding a couple of lines
    to a specific profile (iirc).

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

    Thoughts, arguments, suggestions?

    regards,
    trt

    On Sun, May 10, 2009 at 11:15 PM, Bill Keese wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked about
    the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/
    match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
    _______________________________________________
    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/20090514/f32f869a/attachment.htm
  • Karl Tiedt at May 14, 2009 at 12:36 pm
    Sounds like a very well put plan...
    I like the names dijix dijip and dojop :P

    although we are really pushing a lot of name spaces then :P

    I would be +1 for something like this as well, it would certainly clear up a
    few headaches

    -Karl Tiedt


    2009/5/14 Mike Wilcox <mwilcox at sitepen.com>
    +1
    I like the DijitX idea. It fills out the plan nicely. Now we can start
    think of the 'X' to mean 'extension', and not 'experimental'.

    Suggested additions to Tom's list for promotion to Dojo: validation and
    json stuff. DropDownSelect should be promoted to Dijit if it's ready.

    One of the reasons I like the plugin concept is because currently there's
    no criteria to determine the popularity or usefulness of... well anything in
    Dojo. Having plugins allows for download tracking and a rating vote.

    I think there should definitely be an official plugin location for previous
    DojoX work, and stuff that has a CLA. Seems that the requirements for
    submission would be fairly light. Then an unofficial plugin location for
    non-cla work.

    I feel I have to vote against Adam's suggestion that plugins be what are
    currently packages in DojoX. I think each file should be a plugin, except
    for cases where they are a package in themselves (like lang for example).

    Namespace for a plugin? dojop? Should there be a dijitp?

    dojo, dijit, dojox, dijitx, dojop (dijitp)

    Mike Wilcox


    On May 14, 2009, at 10:28 AM, Tom Trenka wrote:

    I've been kicking around some ideas, and I think at this point I'd like to
    promote what many of you might consider to be radical changes. Please bear
    with me on this and recognize that what I'm proposing here is meant to begin
    some real discussions...right now, I would be considering this proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release. Probably
    most would rather consider it for 2.0 but since our release cycles tend to
    be pushed way out, I think it's reasonable to consider this for an earlier
    major milestone...
    1.5: *Promote DojoX to be a true first-class citizen in the Dojosphere*.
    This may seem like an odd thing to say, but allow me to explain.
    Currently, DojoX is used for all sorts of different purposes--for some
    things, it's a breeding ground for eventual migration; for some, it's a
    playground; for others, it's like a personal repo.

    I would like this to change.

    The goal here would be to couple DojoX releases with the Core (and not
    Dijit, I'll get to that), so that the two projects are considered congruent.
    This means that the idea of trying to package individual projects in DojoX
    is no longer a necessity.

    In order for this to happen, I think we need to make the following changes,
    both directly to DojoX and also in the rules overseeing DojoX:

    *1. Migrate the pieces in DojoX that should be migrated.*
    On my list of things here, the following should be migrated to Core: gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit with all
    possible speed.

    *2. Make decisions on what current parts of DojoX should remain, as worthy
    parts of a core release.*
    The criteria here is that whatever remains needs to have the following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular basis.
    c. having a focus that is part of the long term goals of the toolkit
    itself.
    d. is and continues to be under active development, if not entirely stable.

    On my short list here is FX, the Charting package, and (at least) Cometd.
    What else ends up on this list is entirely up to discussion but I would
    like to keep it short and solid; for example, I would consider Storage to be
    a candidate but I'm not sure about off, etc.

    *3. Move everything else out of DojoX and out of the release cycle.*
    Before anyone starts saying "hey, what the hell", hear me out.

    There are a lot of things sitting in DojoX currently that have only one
    developer, is not under active development, serves only a single party's
    needs, etc. etc. Most of these projects, while some are very interesting,
    should really not be a part of a Dojo release cycle at all (and I think this
    is one of the reasons why we've been going back and forth on the whole
    separate package thing), and so I think we should be moving them out of
    DojoX altogether. Things on this list (IMHO) include analytics, av, wires,
    sketch, collections, encoding, and more.

    However, I don't think we should be losing any of these projects either,
    so...

    *4. Take over the dojoc concept and rename it to something like "dplug",
    "plug" or "plugins".*
    But I'm going to simplify this idea (after talking it over with Dustin);
    what we basically do is this:

    a. allow anyone with current ownership of a DojoX project to choose how
    they would like to maintain the code (i.e. whether they want to move to a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would be what is
    currently the dojoc concept, but renamed to something like the above.
    c. With every Dojo release, provide an empty directory at the same level
    as dojo, dijit and dojox--named the above.

    The idea here is to allow *anyone* to use that namespace as an automatic
    way of being able to drop plugins into an existing Dojo release, not have to
    worry about registering a namespace, and being able to instantly go with
    whatever code they want. It'd also allow us to maintain a place where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release cycle.

    It should also allow whoever to be able to do builds without a huge amount
    of extra pain.
    -----------------

    There are a few things that I have deliberately left out of this--the
    biggest one being anything that is currently in DojoX that is widget-based.
    I have a proposal for this as well but I am unsure if it's the right way to
    go; however, I do feel that DojoX is no longer a place that widgets should
    be in and it should be congruent to Core and only Core.

    To this end, I might suggest *creating a DijitX project*--which would
    serve the same purpose for Dijit as DojoX does for Core. Anything
    widget-based that the Dijit team feels is a good add-on to Dijit without
    having to satisfy the same stringent requirements can go in there.

    In my mind though, the main thing is that anything in the streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------

    While aggressive, I think that this kind of change is definitely do-able
    for the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub files in
    DojoX with deprecation messages for existing users, and make sure that users
    of that codebase can find the new locations of their project dependency.

    I'm proposing this idea because it seems to me like it kills several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that writing
    them is a simple matter of saying "call it plugin.foo and drop it in here".
    6. The build system can pick up plugins by adding a couple of lines to a
    specific profile (iirc).

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

    Thoughts, arguments, suggestions?

    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese wrote:

    Hi Sam,

    I don't have anything new to add since the last time we talked about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
    _______________________________________________
    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090514/3c185774/attachment-0001.htm
  • Adam Peller at May 14, 2009 at 12:51 pm
    -1. Far too aggressive. I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into the
    release process. I think we need to break things out. For marketing
    and practical reasons, we need a very tiny base or core and everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) Just in the last couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. These were two of the candidates for migrating into our
    main release. As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point I'd like to
    promote what many of you might consider to be radical changes. ?Please bear
    with me on this and recognize that what I'm proposing here is meant to begin
    some real discussions...right now, I would be considering this proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release. ?Probably
    most would rather consider it for 2.0 but since our release cycles tend to
    be pushed way out, I think it's reasonable to consider this for an earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the Dojosphere.
    This may seem like an odd thing to say, but allow me to explain. ?Currently,
    DojoX is used for all sorts of different purposes--for some things, it's a
    breeding ground for eventual migration; for some, it's a playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core (and not
    Dijit, I'll get to that), so that the two projects are considered congruent.
    ?This means that the idea of trying to package individual projects in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to Core: ?gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a semi-regular
    basis.
    c. having a focus that is part of the long term goals of the toolkit itself.
    d. is and continues to be under active development, if not entirely stable.
    On my short list here is FX, the Charting package, and (at least) Cometd.
    ?What else ends up on this list is entirely up to discussion but I would
    like to keep it short and solid; for example, I would consider Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have only one
    developer, is not under active development, serves only a single party's
    needs, etc. etc. ?Most of these projects, while some are very interesting,
    should really not be a part of a Dojo release cycle at all (and I think this
    is one of the reasons why we've been going back and forth on the whole
    separate package thing), and so I think we should be moving them out of
    DojoX altogether. ?Things on this list (IMHO) include analytics, av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects either,
    so...

    4. Take over the dojoc concept and rename it to something like "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with Dustin);
    what we basically do is this:
    a. ?allow anyone with current ownership of a DojoX project to choose how
    they would like to maintain the code (i.e. whether they want to move to a
    different repo system or not).
    b. ?Provide a repo that is *not* on a release cycle; this would be what is
    currently the dojoc concept, but renamed to something like the above.
    c. ?With every Dojo release, provide an empty directory at the same level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an automatic way
    of being able to drop plugins into an existing Dojo release, not have to
    worry about registering a namespace, and being able to instantly go with
    whatever code they want. ?It'd also allow us to maintain a place where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release cycle.
    It should also allow whoever to be able to do builds without a huge amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--the
    biggest one being anything that is currently in DojoX that is widget-based.
    ?I have a proposal for this as well but I am unsure if it's the right way to
    go; however, I do feel that DojoX is no longer a place that widgets should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would serve
    the same purpose for Dijit as DojoX does for Core. ?Anything widget-based
    that the Dijit team feels is a good add-on to Dijit without having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely do-able for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub files in
    DojoX with deprecation messages for existing users, and make sure that users
    of that codebase can find the new locations of their project dependency.
    I'm proposing this idea because it seems to me like it kills several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that writing
    them is a simple matter of saying "call it plugin.foo and drop it in here".
    6. The build system can pick up plugins by adding a couple of lines to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese wrote:

    Hi Sam,

    I don't have anything new to add since the last time we talked about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
    _______________________________________________
    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
  • Tom Trenka at May 14, 2009 at 12:58 pm
    I think this is a fair argument but I should say that most of these things
    are suggestions; I don't see any reason why releases could continue to be
    decoupled if that's what the community thinks is best.
    The main thing here for me is that we do a DojoX release as a single release
    and not deal with the whole "package each subproject separately" kind of
    thing. Whether or not that release is tied to a Dojo Core release is
    something I think we can figure out.

    trt
    On Thu, May 14, 2009 at 11:51 AM, Adam Peller wrote:

    -1. Far too aggressive. I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into the
    release process. I think we need to break things out. For marketing
    and practical reasons, we need a very tiny base or core and everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) Just in the last couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. These were two of the candidates for migrating into our
    main release. As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point I'd like to
    promote what many of you might consider to be radical changes. Please bear
    with me on this and recognize that what I'm proposing here is meant to begin
    some real discussions...right now, I would be considering this proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release. Probably
    most would rather consider it for 2.0 but since our release cycles tend to
    be pushed way out, I think it's reasonable to consider this for an earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some things, it's a
    breeding ground for eventual migration; for some, it's a playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core (and not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    This means that the idea of trying to package individual projects in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to Core: gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the toolkit itself.
    d. is and continues to be under active development, if not entirely stable.
    On my short list here is FX, the Charting package, and (at least) Cometd.
    What else ends up on this list is entirely up to discussion but I would
    like to keep it short and solid; for example, I would consider Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have only one
    developer, is not under active development, serves only a single party's
    needs, etc. etc. Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I think this
    is one of the reasons why we've been going back and forth on the whole
    separate package thing), and so I think we should be moving them out of
    DojoX altogether. Things on this list (IMHO) include analytics, av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects either,
    so...

    4. Take over the dojoc concept and rename it to something like "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with Dustin);
    what we basically do is this:
    a. allow anyone with current ownership of a DojoX project to choose how
    they would like to maintain the code (i.e. whether they want to move to a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would be what is
    currently the dojoc concept, but renamed to something like the above.
    c. With every Dojo release, provide an empty directory at the same level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an automatic way
    of being able to drop plugins into an existing Dojo release, not have to
    worry about registering a namespace, and being able to instantly go with
    whatever code they want. It'd also allow us to maintain a place where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release cycle.
    It should also allow whoever to be able to do builds without a huge amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    I have a proposal for this as well but I am unsure if it's the right way to
    go; however, I do feel that DojoX is no longer a place that widgets should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would serve
    the same purpose for Dijit as DojoX does for Core. Anything widget-based
    that the Dijit team feels is a good add-on to Dijit without having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely do-able for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub files in
    DojoX with deprecation messages for existing users, and make sure that users
    of that codebase can find the new locations of their project dependency.
    I'm proposing this idea because it seems to me like it kills several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that writing
    them is a simple matter of saying "call it plugin.foo and drop it in here".
    6. The build system can pick up plugins by adding a couple of lines to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese wrote:

    Hi Sam,

    I don't have anything new to add since the last time we talked about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
    _______________________________________________
    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090514/799731bb/attachment-0001.htm
  • Adam Peller at May 14, 2009 at 1:14 pm
    One problem with one big release is coordination -- not really our
    strength :) and not something that scales well We rarely have the
    same level of readiness across project. We usually have spurts of
    activity as developers have time to work on their projects, and our
    releases are largely arbitrary where dojox or peripheral work is
    concerned. At best, we release around dojo and dijit features and try
    to make sure nothing huge broke in dojox. Delays in one section drag
    out the whole release and make it harder for us to push code out. In
    reality, many of the dojox projects mightn not change all that much,
    even the stable, well-used ones, yet users are forced to deal with
    large tarballs with stuff they may not need, large changesets, etc.

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I think this is a fair argument but I should say that most of these things
    are suggestions; I don't see any reason why releases could continue to be
    decoupled if that's what the community thinks is best.
    The main thing here for me is that we do a DojoX release as a single release
    and not deal with the whole "package each subproject separately" kind of
    thing. ?Whether or not that release is tied to a Dojo Core release is
    something I think we can figure out.
    trt
    On Thu, May 14, 2009 at 11:51 AM, Adam Peller wrote:

    -1. ?Far too aggressive. ?I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into the
    release process. ?I think we need to break things out. ?For marketing
    and practical reasons, we need a very tiny base or core and everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) ?Just in the last couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. ?These were two of the candidates for migrating into our
    main release. ?As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point I'd like
    to
    promote what many of you might consider to be radical changes. ?Please
    bear
    with me on this and recognize that what I'm proposing here is meant to
    begin
    some real discussions...right now, I would be considering this proposal
    as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    ?Probably
    most would rather consider it for 2.0 but since our release cycles tend
    to
    be pushed way out, I think it's reasonable to consider this for an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    ?Currently,
    DojoX is used for all sorts of different purposes--for some things, it's
    a
    breeding ground for eventual migration; for some, it's a playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core (and not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    ?This means that the idea of trying to package individual projects in
    DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to Core:
    ?gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit with
    all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the toolkit
    itself.
    d. is and continues to be under active development, if not entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    ?What else ends up on this list is entirely up to discussion but I would
    like to keep it short and solid; for example, I would consider Storage
    to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have only one
    developer, is not under active development, serves only a single party's
    needs, etc. etc. ?Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I think
    this
    is one of the reasons why we've been going back and forth on the whole
    separate package thing), and so I think we should be moving them out of
    DojoX altogether. ?Things on this list (IMHO) include analytics, av,
    wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects either,
    so...

    4. Take over the dojoc concept and rename it to something like "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with Dustin);
    what we basically do is this:
    a. ?allow anyone with current ownership of a DojoX project to choose how
    they would like to maintain the code (i.e. whether they want to move to
    a
    different repo system or not).
    b. ?Provide a repo that is *not* on a release cycle; this would be what
    is
    currently the dojoc concept, but renamed to something like the above.
    c. ?With every Dojo release, provide an empty directory at the same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an automatic
    way
    of being able to drop plugins into an existing Dojo release, not have to
    worry about registering a namespace, and being able to instantly go with
    whatever code they want. ?It'd also allow us to maintain a place where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release
    cycle.
    It should also allow whoever to be able to do builds without a huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    ?I have a proposal for this as well but I am unsure if it's the right
    way to
    go; however, I do feel that DojoX is no longer a place that widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would
    serve
    the same purpose for Dijit as DojoX does for Core. ?Anything
    widget-based
    that the Dijit team feels is a good add-on to Dijit without having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the streamlined
    DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely do-able
    for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub files
    in
    DojoX with deprecation messages for existing users, and make sure that
    users
    of that codebase can find the new locations of their project dependency.
    I'm proposing this idea because it seems to me like it kills several
    birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as essential to
    the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it in
    here".
    6. The build system can pick up plugins by adding a couple of lines to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked about
    the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
    _______________________________________________
    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

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Mike Wilcox at May 14, 2009 at 1:23 pm
    But isn't this alleviated by Tom's plan? I would guess that DojoX and
    DijitX would be about 20-50% the size of the current DojoX.

    Everything else becomes a plugin on its own release cycle. This helps
    dojo users too, who have trouble dealing with a DojoX package in a
    current release, even though it's fixed in the trunk.

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On May 14, 2009, at 12:14 PM, Adam Peller wrote:

    One problem with one big release is coordination -- not really our
    strength :) and not something that scales well We rarely have the
    same level of readiness across project. We usually have spurts of
    activity as developers have time to work on their projects, and our
    releases are largely arbitrary where dojox or peripheral work is
    concerned. At best, we release around dojo and dijit features and try
    to make sure nothing huge broke in dojox. Delays in one section drag
    out the whole release and make it harder for us to push code out. In
    reality, many of the dojox projects mightn not change all that much,
    even the stable, well-used ones, yet users are forced to deal with
    large tarballs with stuff they may not need, large changesets, etc.

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I think this is a fair argument but I should say that most of these
    things
    are suggestions; I don't see any reason why releases could continue
    to be
    decoupled if that's what the community thinks is best.
    The main thing here for me is that we do a DojoX release as a
    single release
    and not deal with the whole "package each subproject separately"
    kind of
    thing. Whether or not that release is tied to a Dojo Core release is
    something I think we can figure out.
    trt

    On Thu, May 14, 2009 at 11:51 AM, Adam Peller <peller at gmail.com>
    wrote:
    -1. Far too aggressive. I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into
    the
    release process. I think we need to break things out. For
    marketing
    and practical reasons, we need a very tiny base or core and
    everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) Just in the last
    couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. These were two of the candidates for migrating into
    our
    main release. As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point
    I'd like
    to
    promote what many of you might consider to be radical changes.
    Please
    bear
    with me on this and recognize that what I'm proposing here is
    meant to
    begin
    some real discussions...right now, I would be considering this
    proposal
    as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release
    cycles tend
    to
    be pushed way out, I think it's reasonable to consider this for an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some
    things, it's
    a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core
    (and not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    This means that the idea of trying to package individual
    projects in
    DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core:
    gfx,
    dtl, portions of io, rpc and data; grid should be migrated to
    Dijit with
    all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit
    itself.
    d. is and continues to be under active development, if not entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    What else ends up on this list is entirely up to discussion but
    I would
    like to keep it short and solid; for example, I would consider
    Storage
    to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have
    only one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think
    this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. Things on this list (IMHO) include analytics,
    av,
    wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to
    a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would
    be what
    is
    currently the dojoc concept, but renamed to something like the
    above.
    c. With every Dojo release, provide an empty directory at the same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic
    way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to instantly
    go with
    whatever code they want. It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release
    cycle.
    It should also allow whoever to be able to do builds without a huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--
    the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    I have a proposal for this as well but I am unsure if it's the
    right
    way to
    go; however, I do feel that DojoX is no longer a place that widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would
    serve
    the same purpose for Dijit as DojoX does for Core. Anything
    widget-based
    that the Dijit team feels is a good add-on to Dijit without
    having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined
    DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely
    do-able
    for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple
    stub files
    in
    DojoX with deprecation messages for existing users, and make sure
    that
    users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several
    birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to
    the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in
    here".
    6. The build system can pick up plugins by adding a couple of
    lines to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about
    the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/
    focus�83
    _______________________________________________
    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

    _______________________________________________
    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 Peller at May 14, 2009 at 1:31 pm
    Well, I see plugins as a benefit and would rather see the 20-50% go
    that route than basically have it continue along the same pattern we
    have now. I'm not sure to what extent Tom's plan is likely to address
    the rest or just leaves it behind since it's the stuff we arguably
    don't care about (granted, some of it should be abandoned/left
    behind!) You might say I favor focusing only on section #4 of Tom's
    plan, but for all of the DojoX code and carefully crafting and
    promoting releases for the pieces that matter.

    -Adam

    On Thu, May 14, 2009 at 1:23 PM, Mike Wilcox wrote:
    But isn't this alleviated by Tom's plan? I would guess that DojoX and
    DijitX would be about 20-50% the size of the current DojoX.

    Everything else becomes a plugin on its own release cycle. This helps
    dojo users too, who have trouble dealing with a DojoX package in a
    current release, even though it's fixed in the trunk.

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: ? ? 214.697.4872
    On May 14, 2009, at 12:14 PM, Adam Peller wrote:

    One problem with one big release is coordination -- not really our
    strength :) and not something that scales well ?We rarely have the
    same level of readiness across project. ?We usually have spurts of
    activity as developers have time to work on their projects, and our
    releases are largely arbitrary where dojox or peripheral work is
    concerned. ?At best, we release around dojo and dijit features and try
    to make sure nothing huge broke in dojox. ?Delays in one section drag
    out the whole release and make it harder for us to push code out. ?In
    reality, many of the dojox projects mightn not change all that much,
    even the stable, well-used ones, yet users are forced to deal with
    large tarballs with stuff they may not need, large changesets, etc.

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I think this is a fair argument but I should say that most of these
    things
    are suggestions; I don't see any reason why releases could continue
    to be
    decoupled if that's what the community thinks is best.
    The main thing here for me is that we do a DojoX release as a
    single release
    and not deal with the whole "package each subproject separately"
    kind of
    thing. ?Whether or not that release is tied to a Dojo Core release is
    something I think we can figure out.
    trt

    On Thu, May 14, 2009 at 11:51 AM, Adam Peller <peller at gmail.com>
    wrote:
    -1. ?Far too aggressive. ?I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into
    the
    release process. ?I think we need to break things out. ?For
    marketing
    and practical reasons, we need a very tiny base or core and
    everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) ?Just in the last
    couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. ?These were two of the candidates for migrating into
    our
    main release. ?As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point
    I'd like
    to
    promote what many of you might consider to be radical changes.
    Please
    bear
    with me on this and recognize that what I'm proposing here is
    meant to
    begin
    some real discussions...right now, I would be considering this
    proposal
    as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    ?Probably
    most would rather consider it for 2.0 but since our release
    cycles tend
    to
    be pushed way out, I think it's reasonable to consider this for an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    ?Currently,
    DojoX is used for all sorts of different purposes--for some
    things, it's
    a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core
    (and not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    ?This means that the idea of trying to package individual
    projects in
    DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core:
    ?gfx,
    dtl, portions of io, rpc and data; grid should be migrated to
    Dijit with
    all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit
    itself.
    d. is and continues to be under active development, if not entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    ?What else ends up on this list is entirely up to discussion but
    I would
    like to keep it short and solid; for example, I would consider
    Storage
    to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have
    only one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. ?Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think
    this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. ?Things on this list (IMHO) include analytics,
    av,
    wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. ?allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to
    a
    different repo system or not).
    b. ?Provide a repo that is *not* on a release cycle; this would
    be what
    is
    currently the dojoc concept, but renamed to something like the
    above.
    c. ?With every Dojo release, provide an empty directory at the same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic
    way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to instantly
    go with
    whatever code they want. ?It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release
    cycle.
    It should also allow whoever to be able to do builds without a huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--
    the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    ?I have a proposal for this as well but I am unsure if it's the
    right
    way to
    go; however, I do feel that DojoX is no longer a place that widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would
    serve
    the same purpose for Dijit as DojoX does for Core. ?Anything
    widget-based
    that the Dijit team feels is a good add-on to Dijit without
    having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined
    DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely
    do-able
    for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple
    stub files
    in
    DojoX with deprecation messages for existing users, and make sure
    that
    users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several
    birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to
    the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in
    here".
    6. The build system can pick up plugins by adding a couple of
    lines to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about
    the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/
    focus�83
    _______________________________________________
    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

    _______________________________________________
    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
  • Mike Wilcox at May 14, 2009 at 1:05 pm
    I agree that maybe some of these things shouldn't be promoted. Grid
    isn't ready. Data probably isn't ready (too fragmented - better as
    Xtensions)

    But I think GFX should be "native" to Dojo. The RPC and Json stuff as
    well.

    Otherwise, you didn't really give a reason for the -1, other than it
    being "aggressive". How is this that different from previous
    suggestions? Dojo is getting fat. Needs to go on a crash diet! Needs
    its stomach stapled!

    Mike Wilcox
    On May 14, 2009, at 11:51 AM, Adam Peller wrote:

    -1. Far too aggressive. I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into the
    release process. I think we need to break things out. For marketing
    and practical reasons, we need a very tiny base or core and everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) Just in the last couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. These were two of the candidates for migrating into our
    main release. As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point I'd
    like to
    promote what many of you might consider to be radical changes.
    Please bear
    with me on this and recognize that what I'm proposing here is meant
    to begin
    some real discussions...right now, I would be considering this
    proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release cycles
    tend to
    be pushed way out, I think it's reasonable to consider this for an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some things,
    it's a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core (and
    not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    This means that the idea of trying to package individual projects
    in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit
    with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit itself.
    d. is and continues to be under active development, if not entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    What else ends up on this list is entirely up to discussion but I
    would
    like to keep it short and solid; for example, I would consider
    Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have only
    one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. Things on this list (IMHO) include analytics,
    av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would be
    what is
    currently the dojoc concept, but renamed to something like the above.
    c. With every Dojo release, provide an empty directory at the same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to instantly go
    with
    whatever code they want. It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release
    cycle.
    It should also allow whoever to be able to do builds without a huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    I have a proposal for this as well but I am unsure if it's the
    right way to
    go; however, I do feel that DojoX is no longer a place that widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would
    serve
    the same purpose for Dijit as DojoX does for Core. Anything widget-
    based
    that the Dijit team feels is a good add-on to Dijit without having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely do-
    able for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub
    files in
    DojoX with deprecation messages for existing users, and make sure
    that users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in here".
    6. The build system can pick up plugins by adding a couple of lines
    to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
    _______________________________________________
    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 Peller at May 14, 2009 at 1:16 pm
    What does it really buy us to make GFX "native" to Dojo? Instead, it
    could be a popular plugin. More popular than Dojo itself, perhaps,
    who knows?

    I could certainly see the down side to moving more code (like gfx)
    into the core release, and I just don't see the benefit.

    -Adam
    On Thu, May 14, 2009 at 1:05 PM, Mike Wilcox wrote:
    I agree that maybe some of these things shouldn't be promoted. Grid
    isn't ready. Data probably isn't ready (too fragmented - better as
    Xtensions)

    But I think GFX should be "native" to Dojo. The RPC and Json stuff as
    well.

    Otherwise, you didn't really give a reason for the -1, other than it
    being "aggressive". How is this that different from previous
    suggestions? Dojo is getting fat. Needs to go on a crash diet! Needs
    its stomach stapled!

    Mike Wilcox
    On May 14, 2009, at 11:51 AM, Adam Peller wrote:

    -1. ?Far too aggressive. ?I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into the
    release process. ?I think we need to break things out. ?For marketing
    and practical reasons, we need a very tiny base or core and everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) ?Just in the last couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. ?These were two of the candidates for migrating into our
    main release. ?As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point I'd
    like to
    promote what many of you might consider to be radical changes.
    Please bear
    with me on this and recognize that what I'm proposing here is meant
    to begin
    some real discussions...right now, I would be considering this
    proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release cycles
    tend to
    be pushed way out, I think it's reasonable to consider this for an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some things,
    it's a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core (and
    not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    ?This means that the idea of trying to package individual projects
    in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: ?gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit
    with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit itself.
    d. is and continues to be under active development, if not entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    ?What else ends up on this list is entirely up to discussion but I
    would
    like to keep it short and solid; for example, I would consider
    Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have only
    one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. ?Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. ?Things on this list (IMHO) include analytics,
    av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. ?allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to a
    different repo system or not).
    b. ?Provide a repo that is *not* on a release cycle; this would be
    what is
    currently the dojoc concept, but renamed to something like the above.
    c. ?With every Dojo release, provide an empty directory at the same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to instantly go
    with
    whatever code they want. ?It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release
    cycle.
    It should also allow whoever to be able to do builds without a huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    ?I have a proposal for this as well but I am unsure if it's the
    right way to
    go; however, I do feel that DojoX is no longer a place that widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would
    serve
    the same purpose for Dijit as DojoX does for Core. ?Anything widget-
    based
    that the Dijit team feels is a good add-on to Dijit without having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely do-
    able for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub
    files in
    DojoX with deprecation messages for existing users, and make sure
    that users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in here".
    6. The build system can pick up plugins by adding a couple of lines
    to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
    _______________________________________________
    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
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Mike Wilcox at May 14, 2009 at 1:22 pm
    Marketing. What other library has native GFX?

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On May 14, 2009, at 12:16 PM, Adam Peller wrote:

    What does it really buy us to make GFX "native" to Dojo? Instead, it
    could be a popular plugin. More popular than Dojo itself, perhaps,
    who knows?

    I could certainly see the down side to moving more code (like gfx)
    into the core release, and I just don't see the benefit.

    -Adam
    On Thu, May 14, 2009 at 1:05 PM, Mike Wilcox wrote:
    I agree that maybe some of these things shouldn't be promoted. Grid
    isn't ready. Data probably isn't ready (too fragmented - better as
    Xtensions)

    But I think GFX should be "native" to Dojo. The RPC and Json stuff as
    well.

    Otherwise, you didn't really give a reason for the -1, other than it
    being "aggressive". How is this that different from previous
    suggestions? Dojo is getting fat. Needs to go on a crash diet! Needs
    its stomach stapled!

    Mike Wilcox
    On May 14, 2009, at 11:51 AM, Adam Peller wrote:

    -1. Far too aggressive. I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into
    the
    release process. I think we need to break things out. For
    marketing
    and practical reasons, we need a very tiny base or core and
    everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) Just in the last
    couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. These were two of the candidates for migrating into
    our
    main release. As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point I'd
    like to
    promote what many of you might consider to be radical changes.
    Please bear
    with me on this and recognize that what I'm proposing here is meant
    to begin
    some real discussions...right now, I would be considering this
    proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release cycles
    tend to
    be pushed way out, I think it's reasonable to consider this for an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some things,
    it's a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core (and
    not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    This means that the idea of trying to package individual projects
    in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit
    with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit itself.
    d. is and continues to be under active development, if not entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    What else ends up on this list is entirely up to discussion but I
    would
    like to keep it short and solid; for example, I would consider
    Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have only
    one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. Things on this list (IMHO) include analytics,
    av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would be
    what is
    currently the dojoc concept, but renamed to something like the
    above.
    c. With every Dojo release, provide an empty directory at the same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to instantly go
    with
    whatever code they want. It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release
    cycle.
    It should also allow whoever to be able to do builds without a huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--
    the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    I have a proposal for this as well but I am unsure if it's the
    right way to
    go; however, I do feel that DojoX is no longer a place that widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would
    serve
    the same purpose for Dijit as DojoX does for Core. Anything
    widget-
    based
    that the Dijit team feels is a good add-on to Dijit without
    having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely
    do-
    able for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub
    files in
    DojoX with deprecation messages for existing users, and make sure
    that users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in here".
    6. The build system can pick up plugins by adding a couple of lines
    to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/
    focus�83
    _______________________________________________
    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
    _______________________________________________
    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 Peller at May 14, 2009 at 1:26 pm
    We can promote the crap out of it if you like. Even prepare a special
    dojo+gfx zip, if avoiding the extra click is really going to help
    people. That doesn't mean it has to be in the dojo release all the
    time or be part of the same release cycle or even be in the same
    namespace. How does coupling all this together help our marketing?

    -Adam
    On Thu, May 14, 2009 at 1:22 PM, Mike Wilcox wrote:
    Marketing. What other library has native GFX?

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: ? ? 214.697.4872
    On May 14, 2009, at 12:16 PM, Adam Peller wrote:

    What does it really buy us to make GFX "native" to Dojo? ?Instead, it
    could be a popular plugin. ?More popular than Dojo itself, perhaps,
    who knows?

    I could certainly see the down side to moving more code (like gfx)
    into the core release, and I just don't see the benefit.

    -Adam

    On Thu, May 14, 2009 at 1:05 PM, Mike Wilcox <mwilcox at sitepen.com>
    wrote:
    I agree that maybe some of these things shouldn't be promoted. Grid
    isn't ready. Data probably isn't ready (too fragmented - better as
    Xtensions)

    But I think GFX should be "native" to Dojo. The RPC and Json stuff as
    well.

    Otherwise, you didn't really give a reason for the -1, other than it
    being "aggressive". How is this that different from previous
    suggestions? Dojo is getting fat. Needs to go on a crash diet! Needs
    its stomach stapled!

    Mike Wilcox
    On May 14, 2009, at 11:51 AM, Adam Peller wrote:

    -1. ?Far too aggressive. ?I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into
    the
    release process. ?I think we need to break things out. ?For
    marketing
    and practical reasons, we need a very tiny base or core and
    everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) ?Just in the last
    couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. ?These were two of the candidates for migrating into
    our
    main release. ?As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point I'd
    like to
    promote what many of you might consider to be radical changes.
    Please bear
    with me on this and recognize that what I'm proposing here is meant
    to begin
    some real discussions...right now, I would be considering this
    proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release cycles
    tend to
    be pushed way out, I think it's reasonable to consider this for an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some things,
    it's a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core (and
    not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    ?This means that the idea of trying to package individual projects
    in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: ?gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit
    with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit itself.
    d. is and continues to be under active development, if not entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    ?What else ends up on this list is entirely up to discussion but I
    would
    like to keep it short and solid; for example, I would consider
    Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have only
    one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. ?Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. ?Things on this list (IMHO) include analytics,
    av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. ?allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to a
    different repo system or not).
    b. ?Provide a repo that is *not* on a release cycle; this would be
    what is
    currently the dojoc concept, but renamed to something like the
    above.
    c. ?With every Dojo release, provide an empty directory at the same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to instantly go
    with
    whatever code they want. ?It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release
    cycle.
    It should also allow whoever to be able to do builds without a huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--
    the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    ?I have a proposal for this as well but I am unsure if it's the
    right way to
    go; however, I do feel that DojoX is no longer a place that widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would
    serve
    the same purpose for Dijit as DojoX does for Core. ?Anything
    widget-
    based
    that the Dijit team feels is a good add-on to Dijit without
    having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely
    do-
    able for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub
    files in
    DojoX with deprecation messages for existing users, and make sure
    that users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in here".
    6. The build system can pick up plugins by adding a couple of lines
    to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/
    focus�83
    _______________________________________________
    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
    _______________________________________________
    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
  • Nathan Toone at May 14, 2009 at 1:34 pm
    I tend to agree here - I, personally in the projects I use, have no
    use of gfx...and would prefer not to have the bloat of having it in
    dojo core.

    I think that it goes back to what Mike said about download
    tracking...although *we* may think that gfx is cool...we aren't the
    ones actually out there using it - and we should probably do some
    download tracking on it before we actually promote anything. If
    downloads of the gfx "plugin" or "extension" (or whatever we want to
    call it) are near the number of downloads for the core dojo release,
    then we include it...but not until then.

    -Nathan
    On May 14, 2009, at 11:26 AM, Adam Peller wrote:

    We can promote the crap out of it if you like. Even prepare a special
    dojo+gfx zip, if avoiding the extra click is really going to help
    people. That doesn't mean it has to be in the dojo release all the
    time or be part of the same release cycle or even be in the same
    namespace. How does coupling all this together help our marketing?

    -Adam
    On Thu, May 14, 2009 at 1:22 PM, Mike Wilcox wrote:
    Marketing. What other library has native GFX?

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On May 14, 2009, at 12:16 PM, Adam Peller wrote:

    What does it really buy us to make GFX "native" to Dojo? Instead,
    it
    could be a popular plugin. More popular than Dojo itself, perhaps,
    who knows?

    I could certainly see the down side to moving more code (like gfx)
    into the core release, and I just don't see the benefit.

    -Adam

    On Thu, May 14, 2009 at 1:05 PM, Mike Wilcox <mwilcox at sitepen.com>
    wrote:
    I agree that maybe some of these things shouldn't be promoted. Grid
    isn't ready. Data probably isn't ready (too fragmented - better as
    Xtensions)

    But I think GFX should be "native" to Dojo. The RPC and Json
    stuff as
    well.

    Otherwise, you didn't really give a reason for the -1, other than
    it
    being "aggressive". How is this that different from previous
    suggestions? Dojo is getting fat. Needs to go on a crash diet!
    Needs
    its stomach stapled!

    Mike Wilcox
    On May 14, 2009, at 11:51 AM, Adam Peller wrote:

    -1. Far too aggressive. I know I disagree with folks on this
    don't
    see the benefit of migrating more into core or coupling more into
    the
    release process. I think we need to break things out. For
    marketing
    and practical reasons, we need a very tiny base or core and
    everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) Just in the last
    couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant
    with a
    new codebase. These were two of the candidates for migrating into
    our
    main release. As separate components, they can have a life of
    their
    own, still under the Dojo license and CLA agreement, with their
    own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point
    I'd
    like to
    promote what many of you might consider to be radical changes.
    Please bear
    with me on this and recognize that what I'm proposing here is
    meant
    to begin
    some real discussions...right now, I would be considering this
    proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release
    cycles
    tend to
    be pushed way out, I think it's reasonable to consider this for
    an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some
    things,
    it's a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core
    (and
    not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    This means that the idea of trying to package individual
    projects
    in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the
    following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: gfx,
    dtl, portions of io, rpc and data; grid should be migrated to
    Dijit
    with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain,
    as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit itself.
    d. is and continues to be under active development, if not
    entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    What else ends up on this list is entirely up to discussion
    but I
    would
    like to keep it short and solid; for example, I would consider
    Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release
    cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have
    only
    one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. Things on this list (IMHO) include analytics,
    av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would
    be
    what is
    currently the dojoc concept, but renamed to something like the
    above.
    c. With every Dojo release, provide an empty directory at the
    same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to
    instantly go
    with
    whatever code they want. It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo
    active
    development (if so desired) without having to be tied to a
    release
    cycle.
    It should also allow whoever to be able to do builds without a
    huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of
    this--
    the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    I have a proposal for this as well but I am unsure if it's the
    right way to
    go; however, I do feel that DojoX is no longer a place that
    widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which
    would
    serve
    the same purpose for Dijit as DojoX does for Core. Anything
    widget-
    based
    that the Dijit team feels is a good add-on to Dijit without
    having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely
    do-
    able for
    the 1.5 release (since it should not radically affect the other
    two
    projects); for backwards-compatibility, we can include simple
    stub
    files in
    DojoX with deprecation messages for existing users, and make sure
    that users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so
    that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in here".
    6. The build system can pick up plugins by adding a couple of
    lines
    to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/
    focus�83
    _______________________________________________
    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
    _______________________________________________
    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
    _______________________________________________
    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: 2433 bytes
    Desc: not available
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090514/f765afa4/attachment-0001.p7s
  • Mike Wilcox at May 14, 2009 at 1:43 pm
    Basically, I look at DojoX and ask myself what should be "Dojo".
    Excluding widgets, there's not much. I may have been too excited about
    the json stuff, just because I'm impressed with its performance. It's
    tied to dojox data, so maybe it should remain.

    By the same token I think embed should be promoted, albeit not yet, as
    it's not ready. Dojo should be able to handle embedding stuff for you,
    which can be very difficult. Look at that embed.Flash. It's crazy
    hard, considering it's "Flash".

    GFX is something of a gem and I believe it should get added focus.
    It's a very mature piece of code and boosts Dojos status.

    Addressing Nathan, I'd argue: what's the difference in terms of bloat
    or weight if GFX is in DojoX or Dojo? It still gets downloaded, and it
    still needs to be required. I agree that it probably is not used much,
    but if promoted, maybe it would get used more.

    I'd also suggest changing the name of the package from "gfx" to
    "letsSeeJqueryDoThis".


    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On May 14, 2009, at 12:26 PM, Adam Peller wrote:

    We can promote the crap out of it if you like. Even prepare a special
    dojo+gfx zip, if avoiding the extra click is really going to help
    people. That doesn't mean it has to be in the dojo release all the
    time or be part of the same release cycle or even be in the same
    namespace. How does coupling all this together help our marketing?

    -Adam
    On Thu, May 14, 2009 at 1:22 PM, Mike Wilcox wrote:
    Marketing. What other library has native GFX?

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On May 14, 2009, at 12:16 PM, Adam Peller wrote:

    What does it really buy us to make GFX "native" to Dojo? Instead,
    it
    could be a popular plugin. More popular than Dojo itself, perhaps,
    who knows?

    I could certainly see the down side to moving more code (like gfx)
    into the core release, and I just don't see the benefit.

    -Adam

    On Thu, May 14, 2009 at 1:05 PM, Mike Wilcox <mwilcox at sitepen.com>
    wrote:
    I agree that maybe some of these things shouldn't be promoted. Grid
    isn't ready. Data probably isn't ready (too fragmented - better as
    Xtensions)

    But I think GFX should be "native" to Dojo. The RPC and Json
    stuff as
    well.

    Otherwise, you didn't really give a reason for the -1, other than
    it
    being "aggressive". How is this that different from previous
    suggestions? Dojo is getting fat. Needs to go on a crash diet!
    Needs
    its stomach stapled!

    Mike Wilcox
    On May 14, 2009, at 11:51 AM, Adam Peller wrote:

    -1. Far too aggressive. I know I disagree with folks on this
    don't
    see the benefit of migrating more into core or coupling more into
    the
    release process. I think we need to break things out. For
    marketing
    and practical reasons, we need a very tiny base or core and
    everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) Just in the last
    couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant
    with a
    new codebase. These were two of the candidates for migrating into
    our
    main release. As separate components, they can have a life of
    their
    own, still under the Dojo license and CLA agreement, with their
    own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point
    I'd
    like to
    promote what many of you might consider to be radical changes.
    Please bear
    with me on this and recognize that what I'm proposing here is
    meant
    to begin
    some real discussions...right now, I would be considering this
    proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release
    cycles
    tend to
    be pushed way out, I think it's reasonable to consider this for
    an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some
    things,
    it's a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core
    (and
    not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    This means that the idea of trying to package individual
    projects
    in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the
    following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: gfx,
    dtl, portions of io, rpc and data; grid should be migrated to
    Dijit
    with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain,
    as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit itself.
    d. is and continues to be under active development, if not
    entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    What else ends up on this list is entirely up to discussion
    but I
    would
    like to keep it short and solid; for example, I would consider
    Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release
    cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have
    only
    one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. Things on this list (IMHO) include analytics,
    av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would
    be
    what is
    currently the dojoc concept, but renamed to something like the
    above.
    c. With every Dojo release, provide an empty directory at the
    same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to
    instantly go
    with
    whatever code they want. It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo
    active
    development (if so desired) without having to be tied to a
    release
    cycle.
    It should also allow whoever to be able to do builds without a
    huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of
    this--
    the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    I have a proposal for this as well but I am unsure if it's the
    right way to
    go; however, I do feel that DojoX is no longer a place that
    widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which
    would
    serve
    the same purpose for Dijit as DojoX does for Core. Anything
    widget-
    based
    that the Dijit team feels is a good add-on to Dijit without
    having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely
    do-
    able for
    the 1.5 release (since it should not radically affect the other
    two
    projects); for backwards-compatibility, we can include simple
    stub
    files in
    DojoX with deprecation messages for existing users, and make sure
    that users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so
    that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in here".
    6. The build system can pick up plugins by adding a couple of
    lines
    to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/
    focus�83
    _______________________________________________
    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
    _______________________________________________
    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
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Tom Trenka at May 14, 2009 at 2:05 pm
    A little explanation on why I mentioned the projects I mentioned for
    promotion:
    All of the items I mentioned (gfx, dtl, grid, portions of rpc, io and data)
    are excellent marketing tools and "value-adds" for helping to sell the Core
    as a superior product as compared to other JS libraries. They things that
    others simply don't have. But at the same time I think a healthy discussion
    around what should and should not either migrate or be migrated is long
    overdue and part of my original "bitching" about coming up with a real
    roadmap.

    If the overall consensus is to not migrate gfx (using that as an example), I
    think that's fine; in that case I think it's important enough to continue to
    be a major feature of DojoX. I would promote it simply because it's an
    excellent foundation upon which other things can be built--and to me that's
    a large portion of the purpose of Core to begin with.

    (You'll notice that I did not advocate promoting Charting to Core; I think
    DojoX is a good place for keeping important things that are not intended to
    have other systems built on top of them.)

    Also keep in mind that I'm not advocating *any* promotion to the Dojo
    Base--this should remain a major concern in terms of keeping the actual
    download size as low as possible.

    Hope that helps,
    trt
    On Thu, May 14, 2009 at 12:43 PM, Mike Wilcox wrote:

    Basically, I look at DojoX and ask myself what should be "Dojo".
    Excluding widgets, there's not much. I may have been too excited about
    the json stuff, just because I'm impressed with its performance. It's
    tied to dojox data, so maybe it should remain.

    By the same token I think embed should be promoted, albeit not yet, as
    it's not ready. Dojo should be able to handle embedding stuff for you,
    which can be very difficult. Look at that embed.Flash. It's crazy
    hard, considering it's "Flash".

    GFX is something of a gem and I believe it should get added focus.
    It's a very mature piece of code and boosts Dojos status.

    Addressing Nathan, I'd argue: what's the difference in terms of bloat
    or weight if GFX is in DojoX or Dojo? It still gets downloaded, and it
    still needs to be required. I agree that it probably is not used much,
    but if promoted, maybe it would get used more.

    I'd also suggest changing the name of the package from "gfx" to
    "letsSeeJqueryDoThis".


    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On May 14, 2009, at 12:26 PM, Adam Peller wrote:

    We can promote the crap out of it if you like. Even prepare a special
    dojo+gfx zip, if avoiding the extra click is really going to help
    people. That doesn't mean it has to be in the dojo release all the
    time or be part of the same release cycle or even be in the same
    namespace. How does coupling all this together help our marketing?

    -Adam

    On Thu, May 14, 2009 at 1:22 PM, Mike Wilcox <mwilcox at sitepen.com>
    wrote:
    Marketing. What other library has native GFX?

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On May 14, 2009, at 12:16 PM, Adam Peller wrote:

    What does it really buy us to make GFX "native" to Dojo? Instead,
    it
    could be a popular plugin. More popular than Dojo itself, perhaps,
    who knows?

    I could certainly see the down side to moving more code (like gfx)
    into the core release, and I just don't see the benefit.

    -Adam

    On Thu, May 14, 2009 at 1:05 PM, Mike Wilcox <mwilcox at sitepen.com>
    wrote:
    I agree that maybe some of these things shouldn't be promoted. Grid
    isn't ready. Data probably isn't ready (too fragmented - better as
    Xtensions)

    But I think GFX should be "native" to Dojo. The RPC and Json
    stuff as
    well.

    Otherwise, you didn't really give a reason for the -1, other than
    it
    being "aggressive". How is this that different from previous
    suggestions? Dojo is getting fat. Needs to go on a crash diet!
    Needs
    its stomach stapled!

    Mike Wilcox
    On May 14, 2009, at 11:51 AM, Adam Peller wrote:

    -1. Far too aggressive. I know I disagree with folks on this
    don't
    see the benefit of migrating more into core or coupling more into
    the
    release process. I think we need to break things out. For
    marketing
    and practical reasons, we need a very tiny base or core and
    everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) Just in the last
    couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant
    with a
    new codebase. These were two of the candidates for migrating into
    our
    main release. As separate components, they can have a life of
    their
    own, still under the Dojo license and CLA agreement, with their
    own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point
    I'd
    like to
    promote what many of you might consider to be radical changes.
    Please bear
    with me on this and recognize that what I'm proposing here is
    meant
    to begin
    some real discussions...right now, I would be considering this
    proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release
    cycles
    tend to
    be pushed way out, I think it's reasonable to consider this for
    an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some
    things,
    it's a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core
    (and
    not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    This means that the idea of trying to package individual
    projects
    in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the
    following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: gfx,
    dtl, portions of io, rpc and data; grid should be migrated to
    Dijit
    with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain,
    as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit itself.
    d. is and continues to be under active development, if not
    entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    What else ends up on this list is entirely up to discussion
    but I
    would
    like to keep it short and solid; for example, I would consider
    Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release
    cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have
    only
    one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. Things on this list (IMHO) include analytics,
    av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would
    be
    what is
    currently the dojoc concept, but renamed to something like the
    above.
    c. With every Dojo release, provide an empty directory at the
    same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to
    instantly go
    with
    whatever code they want. It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo
    active
    development (if so desired) without having to be tied to a
    release
    cycle.
    It should also allow whoever to be able to do builds without a
    huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of
    this--
    the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    I have a proposal for this as well but I am unsure if it's the
    right way to
    go; however, I do feel that DojoX is no longer a place that
    widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which
    would
    serve
    the same purpose for Dijit as DojoX does for Core. Anything
    widget-
    based
    that the Dijit team feels is a good add-on to Dijit without
    having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely
    do-
    able for
    the 1.5 release (since it should not radically affect the other
    two
    projects); for backwards-compatibility, we can include simple
    stub
    files in
    DojoX with deprecation messages for existing users, and make sure
    that users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so
    that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in here".
    6. The build system can pick up plugins by adding a couple of
    lines
    to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about the
    roadmap a few months ago, see:

    -
    http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/
    focus�83
    _______________________________________________
    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
    _______________________________________________
    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
    _______________________________________________
    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/20090514/9bc6a245/attachment-0001.htm
  • Adam Peller at May 14, 2009 at 2:25 pm
    So I like where Revin was heading... I'd be very happy if DojoX went
    away and was just replaced with a bunch of plugins. Same for Core.
    If they happen to continue to have dojox.* as a namespace, so be it,
    but I don't think DojoX should be a marketing point. I think each
    plugin should go on its own merits, ratings and project status will be
    more important, and migrating code becomes irrelevant.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    A little explanation on why I mentioned the projects I mentioned for
    promotion:
    All of the items I mentioned (gfx, dtl, grid, portions of rpc, io and data)
    are excellent marketing tools and "value-adds" for helping to sell the Core
    as a superior product as compared to other JS libraries. ?They things that
    others simply don't have. ?But at the same time I think a healthy discussion
    around what should and should not either migrate or be migrated is long
    overdue and part of my original "bitching" about coming up with a real
    roadmap.
    If the overall consensus is to not migrate gfx (using that as an example), I
    think that's fine; in that case I think it's important enough to continue to
    be a major feature of DojoX. ?I would promote it simply because it's an
    excellent foundation upon which other things can be built--and to me that's
    a large portion of the purpose of Core to begin with.
    (You'll notice that I did not advocate promoting Charting to Core; I think
    DojoX is a good place for keeping important things that are not intended to
    have other systems built on top of them.)
    Also keep in mind that I'm not advocating *any* promotion to the Dojo
    Base--this should remain a major concern in terms of keeping the actual
    download size as low as possible.
    Hope that helps,
    trt
    On Thu, May 14, 2009 at 12:43 PM, Mike Wilcox wrote:

    Basically, I look at DojoX and ask myself what should be "Dojo".
    Excluding widgets, there's not much. I may have been too excited about
    the json stuff, just because I'm impressed with its performance. It's
    tied to dojox data, so maybe it should remain.

    By the same token I think embed should be promoted, albeit not yet, as
    it's not ready. Dojo should be able to handle embedding stuff for you,
    which can be very difficult. Look at that embed.Flash. It's crazy
    hard, considering it's "Flash".

    GFX is something of a gem and I believe it should get added focus.
    It's a very mature piece of code and boosts Dojos status.

    Addressing Nathan, I'd argue: what's the difference in terms of bloat
    or weight if GFX is in DojoX or Dojo? It still gets downloaded, and it
    still needs to be required. I agree that it probably is not used much,
    but if promoted, maybe it would get used more.

    I'd also suggest changing the name of the package from "gfx" to
    "letsSeeJqueryDoThis".


    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: ? ? 214.697.4872
    On May 14, 2009, at 12:26 PM, Adam Peller wrote:

    We can promote the crap out of it if you like. ?Even prepare a special
    dojo+gfx zip, if avoiding the extra click is really going to help
    people. ?That doesn't mean it has to be in the dojo release all the
    time or be part of the same release cycle or even be in the same
    namespace. ?How does coupling all this together help our marketing?

    -Adam

    On Thu, May 14, 2009 at 1:22 PM, Mike Wilcox <mwilcox at sitepen.com>
    wrote:
    Marketing. What other library has native GFX?

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: ? ? 214.697.4872
    On May 14, 2009, at 12:16 PM, Adam Peller wrote:

    What does it really buy us to make GFX "native" to Dojo? ?Instead,
    it
    could be a popular plugin. ?More popular than Dojo itself, perhaps,
    who knows?

    I could certainly see the down side to moving more code (like gfx)
    into the core release, and I just don't see the benefit.

    -Adam

    On Thu, May 14, 2009 at 1:05 PM, Mike Wilcox <mwilcox at sitepen.com>
    wrote:
    I agree that maybe some of these things shouldn't be promoted. Grid
    isn't ready. Data probably isn't ready (too fragmented - better as
    Xtensions)

    But I think GFX should be "native" to Dojo. The RPC and Json
    stuff as
    well.

    Otherwise, you didn't really give a reason for the -1, other than
    it
    being "aggressive". How is this that different from previous
    suggestions? Dojo is getting fat. Needs to go on a crash diet!
    Needs
    its stomach stapled!

    Mike Wilcox
    On May 14, 2009, at 11:51 AM, Adam Peller wrote:

    -1. ?Far too aggressive. ?I know I disagree with folks on this
    don't
    see the benefit of migrating more into core or coupling more into
    the
    release process. ?I think we need to break things out. ?For
    marketing
    and practical reasons, we need a very tiny base or core and
    everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) ?Just in the last
    couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant
    with a
    new codebase. ?These were two of the candidates for migrating into
    our
    main release. ?As separate components, they can have a life of
    their
    own, still under the Dojo license and CLA agreement, with their
    own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point
    I'd
    like to
    promote what many of you might consider to be radical changes.
    Please bear
    with me on this and recognize that what I'm proposing here is
    meant
    to begin
    some real discussions...right now, I would be considering this
    proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release
    cycles
    tend to
    be pushed way out, I think it's reasonable to consider this for
    an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some
    things,
    it's a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core
    (and
    not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    ?This means that the idea of trying to package individual
    projects
    in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the
    following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: ?gfx,
    dtl, portions of io, rpc and data; grid should be migrated to
    Dijit
    with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain,
    as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit itself.
    d. is and continues to be under active development, if not
    entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    ?What else ends up on this list is entirely up to discussion
    but I
    would
    like to keep it short and solid; for example, I would consider
    Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release
    cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have
    only
    one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. ?Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. ?Things on this list (IMHO) include analytics,
    av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. ?allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to a
    different repo system or not).
    b. ?Provide a repo that is *not* on a release cycle; this would
    be
    what is
    currently the dojoc concept, but renamed to something like the
    above.
    c. ?With every Dojo release, provide an empty directory at the
    same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to
    instantly go
    with
    whatever code they want. ?It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo
    active
    development (if so desired) without having to be tied to a
    release
    cycle.
    It should also allow whoever to be able to do builds without a
    huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of
    this--
    the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    ?I have a proposal for this as well but I am unsure if it's the
    right way to
    go; however, I do feel that DojoX is no longer a place that
    widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which
    would
    serve
    the same purpose for Dijit as DojoX does for Core. ?Anything
    widget-
    based
    that the Dijit team feels is a good add-on to Dijit without
    having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely
    do-
    able for
    the 1.5 release (since it should not radically affect the other
    two
    projects); for backwards-compatibility, we can include simple
    stub
    files in
    DojoX with deprecation messages for existing users, and make sure
    that users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so
    that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in here".
    6. The build system can pick up plugins by adding a couple of
    lines
    to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about the
    roadmap a few months ago, see:

    -
    http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/
    focus�83
    _______________________________________________
    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
    _______________________________________________
    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
    _______________________________________________
    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
  • Revin Guillen at May 14, 2009 at 1:26 pm
    It's easier for newcomers to grok the toolkit's structure to think in
    terms of Base == "Dojo", Core == "(official) Plugins." That's not
    exactly what Tom was suggesting, I know, but it's something I've
    advocated before. From a technical perspective, nothing really
    changes, but it seems like simpler marketing overall, and draws a
    clearer logical distinction between DojoX and the core release.

    /my 2c

    --
    Revin Guillen


    On May 14, 2009, at May 14 | 10:16 AM, Adam Peller wrote:

    What does it really buy us to make GFX "native" to Dojo? Instead, it
    could be a popular plugin. More popular than Dojo itself, perhaps,
    who knows?

    I could certainly see the down side to moving more code (like gfx)
    into the core release, and I just don't see the benefit.

    -Adam
    On Thu, May 14, 2009 at 1:05 PM, Mike Wilcox wrote:
    I agree that maybe some of these things shouldn't be promoted. Grid
    isn't ready. Data probably isn't ready (too fragmented - better as
    Xtensions)

    But I think GFX should be "native" to Dojo. The RPC and Json stuff as
    well.

    Otherwise, you didn't really give a reason for the -1, other than it
    being "aggressive". How is this that different from previous
    suggestions? Dojo is getting fat. Needs to go on a crash diet! Needs
    its stomach stapled!

    Mike Wilcox
    On May 14, 2009, at 11:51 AM, Adam Peller wrote:

    -1. Far too aggressive. I know I disagree with folks on this don't
    see the benefit of migrating more into core or coupling more into
    the
    release process. I think we need to break things out. For
    marketing
    and practical reasons, we need a very tiny base or core and
    everything
    else should be separate (we call them dojox subprojects, but if it
    helps to call them plugins instead, so be it) Just in the last
    couple
    of days I've heard discussion about rewriting the grid, and also
    discussion over whether the dojox cometd project is redundant with a
    new codebase. These were two of the candidates for migrating into
    our
    main release. As separate components, they can have a life of their
    own, still under the Dojo license and CLA agreement, with their own
    goals, release cycle, etc.

    -Adam

    2009/5/14 Tom Trenka <ttrenka at gmail.com>:
    I've been kicking around some ideas, and I think at this point I'd
    like to
    promote what many of you might consider to be radical changes.
    Please bear
    with me on this and recognize that what I'm proposing here is meant
    to begin
    some real discussions...right now, I would be considering this
    proposal as a
    (fairly) major reorganization aimed at the 1.5 milestone release.
    Probably
    most would rather consider it for 2.0 but since our release cycles
    tend to
    be pushed way out, I think it's reasonable to consider this for an
    earlier
    major milestone...
    1.5: Promote DojoX to be a true first-class citizen in the
    Dojosphere.
    This may seem like an odd thing to say, but allow me to explain.
    Currently,
    DojoX is used for all sorts of different purposes--for some things,
    it's a
    breeding ground for eventual migration; for some, it's a
    playground; for
    others, it's like a personal repo.
    I would like this to change.
    The goal here would be to couple DojoX releases with the Core (and
    not
    Dijit, I'll get to that), so that the two projects are considered
    congruent.
    This means that the idea of trying to package individual projects
    in DojoX
    is no longer a necessity.
    In order for this to happen, I think we need to make the following
    changes,
    both directly to DojoX and also in the rules overseeing DojoX:
    1. Migrate the pieces in DojoX that should be migrated.
    On my list of things here, the following should be migrated to
    Core: gfx,
    dtl, portions of io, rpc and data; grid should be migrated to Dijit
    with all
    possible speed.
    2. Make decisions on what current parts of DojoX should remain, as
    worthy
    parts of a core release.
    The criteria here is that whatever remains needs to have the
    following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular
    basis.
    c. having a focus that is part of the long term goals of the
    toolkit itself.
    d. is and continues to be under active development, if not entirely
    stable.
    On my short list here is FX, the Charting package, and (at least)
    Cometd.
    What else ends up on this list is entirely up to discussion but I
    would
    like to keep it short and solid; for example, I would consider
    Storage to be
    a candidate but I'm not sure about off, etc.
    3. Move everything else out of DojoX and out of the release cycle.
    Before anyone starts saying "hey, what the hell", hear me out.
    There are a lot of things sitting in DojoX currently that have only
    one
    developer, is not under active development, serves only a single
    party's
    needs, etc. etc. Most of these projects, while some are very
    interesting,
    should really not be a part of a Dojo release cycle at all (and I
    think this
    is one of the reasons why we've been going back and forth on the
    whole
    separate package thing), and so I think we should be moving them
    out of
    DojoX altogether. Things on this list (IMHO) include analytics,
    av, wires,
    sketch, collections, encoding, and more.
    However, I don't think we should be losing any of these projects
    either,
    so...

    4. Take over the dojoc concept and rename it to something like
    "dplug",
    "plug" or "plugins".
    But I'm going to simplify this idea (after talking it over with
    Dustin);
    what we basically do is this:
    a. allow anyone with current ownership of a DojoX project to
    choose how
    they would like to maintain the code (i.e. whether they want to
    move to a
    different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would be
    what is
    currently the dojoc concept, but renamed to something like the
    above.
    c. With every Dojo release, provide an empty directory at the same
    level as
    dojo, dijit and dojox--named the above.
    The idea here is to allow *anyone* to use that namespace as an
    automatic way
    of being able to drop plugins into an existing Dojo release, not
    have to
    worry about registering a namespace, and being able to instantly go
    with
    whatever code they want. It'd also allow us to maintain a place
    where
    projects that have lived under DojoX for a while can undergo active
    development (if so desired) without having to be tied to a release
    cycle.
    It should also allow whoever to be able to do builds without a huge
    amount
    of extra pain.
    -----------------
    There are a few things that I have deliberately left out of this--
    the
    biggest one being anything that is currently in DojoX that is
    widget-based.
    I have a proposal for this as well but I am unsure if it's the
    right way to
    go; however, I do feel that DojoX is no longer a place that widgets
    should
    be in and it should be congruent to Core and only Core.
    To this end, I might suggest creating a DijitX project--which would
    serve
    the same purpose for Dijit as DojoX does for Core. Anything
    widget-
    based
    that the Dijit team feels is a good add-on to Dijit without
    having to
    satisfy the same stringent requirements can go in there.
    In my mind though, the main thing is that anything in the
    streamlined DojoX
    doesn't have or wrap any of the Dijit infrastructure.
    -----------------
    While aggressive, I think that this kind of change is definitely
    do-
    able for
    the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub
    files in
    DojoX with deprecation messages for existing users, and make sure
    that users
    of that codebase can find the new locations of their project
    dependency.
    I'm proposing this idea because it seems to me like it kills
    several birds
    with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more
    playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as
    essential to the
    continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing
    them is a simple matter of saying "call it plugin.foo and drop it
    in here".
    6. The build system can pick up plugins by adding a couple of lines
    to a
    specific profile (iirc).
    -----------------
    Thoughts, arguments, suggestions?
    regards,
    trt
    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
    wrote:
    Hi Sam,

    I don't have anything new to add since the last time we talked
    about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/
    focus�83
    _______________________________________________
    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
    _______________________________________________
    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
  • Eugene Lazutkin at May 15, 2009 at 12:40 am
    I am not answering to Tom's post specifically, just anchoring my post at
    his. :-)

    I think Tom's proposal is well thought-out and I mostly agree with him.
    Rather than position myself on various points of the proposal and the
    ensuing discussion I want to point out things that I feel are missing in
    this discussion: compatibility issues and CDN.

    One big reason to bundle everything together is to put the whole bundle
    on AOL and Google CDNs. Switching pieces of Dojo on their own timetables
    robs us of this opportunity unless we do something about it.

    Actually it is more than just CDN, it is about general scheduling and
    keeping everything in sync. I hate to be in the position when (a
    fictitious example follows) I want to use the grid in my project, but it
    requires Dojo Core 1.4.5 (hypothetically speaking), and DojoX Forms,
    which I want to use too, are still stuck on 1.4.1, while the current
    version of Dojo Core is 1.5.1. We have to have some points of global
    synchronization. Right now when I download Dojo or use it directly from
    CDN I expect that all pieces work together, otherwise it is a bug, which
    will be filed and fixed.

    How to synchronize releases? Dojo Core, the unifying foundation of all
    things Dojo, is a relatively small piece of code and can be
    updated/upgraded quickly. I don't think its cycle can be used as a guidance.

    One more unanswered question: with (hypothetical) upcoming release of
    Dojo Core should we make sure that it doesn't break the current Dijit,
    or should Dijit be tested against the new Dojo Core, and updated if
    needed? In reality it is not a big deal to synchronize Core and Dijit,
    and we managed to do it without any major issues for years, but imagine
    that instead of 3 projects we will have to synchronize 10-15. That can
    be a nightmare unless we have some kind of rules in place.

    Of course we can dictate that minor releases should be always 100%
    backward compatible (the current guideline) and ~100% bug compatible
    (this is the new one) and no major testing is done to ensure that
    everything still works (e.g., we'll be testing Dijit only), major
    releases are global synchronization points, which force all "official"
    players to go through a full compatibility testing exercise. Most
    probably it means that we push to CDN only on major releases.

    Another possible solution is to establish a release schedule with global
    synchronization points scheduled, say, quarterly. In this case whatever
    we have by the end of the quarter is going to be tested, fixed, packaged
    as downloads, and pushed to CDNs. In this case the "level" of release
    doesn't matter at all: we have changes => we release whatever we have at
    the current version guaranteeing that what we pushed out works together.

    Even more questions:

    - - Should we strive to write plugins/modules capable of detecting a Dojo
    Core version and adapting dynamically? As far as I am aware we never did
    it before in Dijit, DojoX, or any other projects. The extra code for
    that can be taxing.

    - - How do we version build tools? Components processed by different build
    tool versions may be incompatible.

    - - How do we test a plugin against different versions of Dojo
    components? Probably we need to set up an automated test bot for that,
    which should be open for a general public to some extent, so people can
    test their components.

    - - Is it even possible to avoid the combinatorial explosion while
    combining different versions in test environments? Do not forget that 10
    components with 2 supported versions give us 1024 different combinations.

    Thanks,

    Eugene Lazutkin
    Dojo Toolkit, Committer
    http://lazutkin.com/
    On 05/14/2009 10:28 AM, Tom Trenka wrote:
    I've been kicking around some ideas, and I think at this point I'd like
    to promote what many of you might consider to be radical changes.
    Please bear with me on this and recognize that what I'm proposing here
    is meant to begin some real discussions...right now, I would be
    considering this proposal as a (fairly) major reorganization aimed at
    the 1.5 milestone release. Probably most would rather consider it for
    2.0 but since our release cycles tend to be pushed way out, I think it's
    reasonable to consider this for an earlier major milestone...

    1.5: /*Promote DojoX to be a true first-class citizen in the Dojosphere*/.
    This may seem like an odd thing to say, but allow me to explain.
    Currently, DojoX is used for all sorts of different purposes--for some
    things, it's a breeding ground for eventual migration; for some, it's a
    playground; for others, it's like a personal repo.

    I would like this to change.

    The goal here would be to couple DojoX releases with the Core (and not
    Dijit, I'll get to that), so that the two projects are considered
    congruent. This means that the idea of trying to package individual
    projects in DojoX is no longer a necessity.

    In order for this to happen, I think we need to make the following
    changes, both directly to DojoX and also in the rules overseeing DojoX:

    *1. Migrate the pieces in DojoX that should be migrated.*
    On my list of things here, the following should be migrated to Core:
    gfx, dtl, portions of io, rpc and data; grid should be migrated to
    Dijit with all possible speed.

    *2. Make decisions on what current parts of DojoX should remain, as
    worthy parts of a core release.*
    The criteria here is that whatever remains needs to have the following
    attributes:
    a. either in beta or stable.
    b. serve a purpose that a typical Dojo consumer would need on a
    semi-regular basis.
    c. having a focus that is part of the long term goals of the toolkit itself.
    d. is and continues to be under active development, if not entirely stable.

    On my short list here is FX, the Charting package, and (at least)
    Cometd. What else ends up on this list is entirely up to discussion but
    I would like to keep it short and solid; for example, I would consider
    Storage to be a candidate but I'm not sure about off, etc.

    *3. Move everything else out of DojoX and out of the release cycle.*
    Before anyone starts saying "hey, what the hell", hear me out.

    There are a lot of things sitting in DojoX currently that have only one
    developer, is not under active development, serves only a single party's
    needs, etc. etc. Most of these projects, while some are very
    interesting, should really not be a part of a Dojo release cycle at all
    (and I think this is one of the reasons why we've been going back and
    forth on the whole separate package thing), and so I think we should be
    moving them out of DojoX altogether. Things on this list (IMHO) include
    analytics, av, wires, sketch, collections, encoding, and more.

    However, I don't think we should be losing any of these projects either,
    so...

    *4. Take over the dojoc concept and rename it to something like "dplug",
    "plug" or "plugins".*
    But I'm going to simplify this idea (after talking it over with Dustin);
    what we basically do is this:

    a. allow anyone with current ownership of a DojoX project to choose how
    they would like to maintain the code (i.e. whether they want to move to
    a different repo system or not).
    b. Provide a repo that is *not* on a release cycle; this would be what
    is currently the dojoc concept, but renamed to something like the above.
    c. With every Dojo release, provide an empty directory at the same
    level as dojo, dijit and dojox--named the above.

    The idea here is to allow *anyone* to use that namespace as an automatic
    way of being able to drop plugins into an existing Dojo release, not
    have to worry about registering a namespace, and being able to instantly
    go with whatever code they want. It'd also allow us to maintain a place
    where projects that have lived under DojoX for a while can undergo
    active development (if so desired) without having to be tied to a
    release cycle.

    It should also allow whoever to be able to do builds without a huge
    amount of extra pain.
    -----------------

    There are a few things that I have deliberately left out of this--the
    biggest one being anything that is currently in DojoX that is
    widget-based. I have a proposal for this as well but I am unsure if
    it's the right way to go; however, I do feel that DojoX is no longer a
    place that widgets should be in and it should be congruent to Core and
    only Core.

    To this end, I might suggest /creating a DijitX project/--which would
    serve the same purpose for Dijit as DojoX does for Core. Anything
    widget-based that the Dijit team feels is a good add-on to Dijit without
    having to satisfy the same stringent requirements can go in there.

    In my mind though, the main thing is that anything in the streamlined
    DojoX doesn't have or wrap any of the Dijit infrastructure.
    -----------------

    While aggressive, I think that this kind of change is definitely do-able
    for the 1.5 release (since it should not radically affect the other two
    projects); for backwards-compatibility, we can include simple stub files
    in DojoX with deprecation messages for existing users, and make sure
    that users of that codebase can find the new locations of their project
    dependency.

    I'm proposing this idea because it seems to me like it kills several
    birds with one stone--
    1. We can clamp down on what goes into DojoX (i.e. no more playground)
    2. We can stop worrying about individual package building
    3. We can continue to couple DojoX to a Core release
    4. We can really start promoting the idea of the plugin as essential to
    the continuing evolvement of DTK
    5. We can provide a basic infrastructure for those plugins so that
    writing them is a simple matter of saying "call it plugin.foo and drop
    it in here".
    6. The build system can pick up plugins by adding a couple of lines to a
    specific profile (iirc).

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

    Thoughts, arguments, suggestions?

    regards,
    trt

    On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org
    wrote:

    Hi Sam,

    I don't have anything new to add since the last time we talked about the
    roadmap a few months ago, see:

    - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
    - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus�83
    _______________________________________________
    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
  • Greg Wilkins at May 18, 2009 at 1:20 am

    Eugene Lazutkin wrote:
    One big reason to bundle everything together is to put the whole bundle
    on AOL and Google CDNs. Switching pieces of Dojo on their own timetables
    robs us of this opportunity unless we do something about it.
    Just because everything is released together does not mean that it
    has to be developed together.

    I invite those reading this thread to have a read of the recent cometd
    threads. The dojox.cometd module is really best developed and hosted
    from the cometd.org project - as that is where is can develop with
    the servers and be free to have it's own lifecycle etc.

    But we want to have a quality dojox.cometd client built into every
    release of dojo, because users just want to be able to do
    dojo.require("dojox.cometd") and have it work in testing, from AOL and
    for building custom releases.

    Thus while I don't know exactly what the solution is for dojox,
    I do think the status quo is problematic.

    cheers

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedMay 6, '09 at 6:43p
activeMay 18, '09 at 1:20a
posts28
users12
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase