[dojo-contributors] dojo roadmap

Karl Tiedt ktiedt at gmail.com
Thu May 14 12:36:09 EDT 2009

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 <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=9783
>> _______________________________________________
>> 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 

More information about the dojo-contributors mailing list