[dojo-contributors] dojo roadmap

Adam Peller peller at gmail.com
Thu May 14 14:25:04 EDT 2009


So I like where Revin was heading... I'd be very happy if DojoX went
away and was just replaced with a bunch of plugins.  Same for Core.
If they happen to continue to have dojox.* as a namespace, so be it,
but I don't think DojoX should be a marketing point.  I think each
plugin should go on its own merits, ratings and project status will be
more important, and migrating code becomes irrelevant.

-Adam

2009/5/14 Tom Trenka <ttrenka at gmail.com>:
> A little explanation on why I mentioned the projects I mentioned for
> promotion:
> All of the items I mentioned (gfx, dtl, grid, portions of rpc, io and data)
> are excellent marketing tools and "value-adds" for helping to sell the Core
> as a superior product as compared to other JS libraries.  They things that
> others simply don't have.  But at the same time I think a healthy discussion
> around what should and should not either migrate or be migrated is long
> overdue and part of my original "bitching" about coming up with a real
> roadmap.
> If the overall consensus is to not migrate gfx (using that as an example), I
> think that's fine; in that case I think it's important enough to continue to
> be a major feature of DojoX.  I would promote it simply because it's an
> excellent foundation upon which other things can be built--and to me that's
> a large portion of the purpose of Core to begin with.
> (You'll notice that I did not advocate promoting Charting to Core; I think
> DojoX is a good place for keeping important things that are not intended to
> have other systems built on top of them.)
> Also keep in mind that I'm not advocating *any* promotion to the Dojo
> Base--this should remain a major concern in terms of keeping the actual
> download size as low as possible.
> Hope that helps,
> trt
> On Thu, May 14, 2009 at 12:43 PM, Mike Wilcox <mwilcox at sitepen.com> wrote:
>>
>> Basically, I look at DojoX and ask myself what should be "Dojo".
>> Excluding widgets, there's not much. I may have been too excited about
>> the json stuff, just because I'm impressed with its performance. It's
>> tied to dojox data, so maybe it should remain.
>>
>> By the same token I think embed should be promoted, albeit not yet, as
>> it's not ready. Dojo should be able to handle embedding stuff for you,
>> which can be very difficult. Look at that embed.Flash. It's crazy
>> hard, considering it's "Flash".
>>
>> GFX is something of a gem and I believe it should get added focus.
>> It's a very mature piece of code and boosts Dojos status.
>>
>> Addressing Nathan, I'd argue: what's the difference in terms of bloat
>> or weight if GFX is in DojoX or Dojo? It still gets downloaded, and it
>> still needs to be required. I agree that it probably is not used much,
>> but if promoted, maybe it would get used more.
>>
>> I'd also suggest changing the name of the package from "gfx" to
>> "letsSeeJqueryDoThis".
>>
>>
>> Mike Wilcox
>> mwilcox at sitepen.com
>> http://www.sitepen.com
>> work: 650.968.8787 x218
>> cell:     214.697.4872
>>
>> On May 14, 2009, at 12:26 PM, Adam Peller wrote:
>>
>> > We can promote the crap out of it if you like.  Even prepare a special
>> > dojo+gfx zip, if avoiding the extra click is really going to help
>> > people.  That doesn't mean it has to be in the dojo release all the
>> > time or be part of the same release cycle or even be in the same
>> > namespace.  How does coupling all this together help our marketing?
>> >
>> > -Adam
>> >
>> > On Thu, May 14, 2009 at 1:22 PM, Mike Wilcox <mwilcox at sitepen.com>
>> > wrote:
>> >> Marketing. What other library has native GFX?
>> >>
>> >> Mike Wilcox
>> >> mwilcox at sitepen.com
>> >> http://www.sitepen.com
>> >> work: 650.968.8787 x218
>> >> cell:     214.697.4872
>> >>
>> >> On May 14, 2009, at 12:16 PM, 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
>> >>>
>> >>
>> >> _______________________________________________
>> >> 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