[dojo-contributors] dojo roadmap
mwilcox at sitepen.com
Thu May 14 12:18:22 EDT 2009
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
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
Namespace for a plugin? dojop? Should there be a dijitp?
dojo, dijit, dojox, dijitx, dojop (dijitp)
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
> 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
> d. is and continues to be under active development, if not entirely
> 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
> In my mind though, the main thing is that anything in the
> streamlined DojoX doesn't have or wrap any of the Dijit
> 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?
> On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
> Hi Sam,
> I don't have anything new to add since the last time we talked about
> roadmap a few months ago, see:
> - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/
> - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus=9783
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors