[dojo-contributors] dojo roadmap

Adam Peller peller at gmail.com
Thu May 14 13:16:36 EDT 2009


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
>


More information about the dojo-contributors mailing list