[dojo-contributors] dojo roadmap

Revin Guillen revin at sitepen.com
Thu May 14 13:26:42 EDT 2009


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