[dojo-contributors] dojo roadmap

Mike Wilcox mwilcox at sitepen.com
Thu May 14 13:05:33 EDT 2009

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  

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

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

More information about the dojo-contributors mailing list