[dojo-contributors] dojo roadmap

Tom Trenka ttrenka at gmail.com
Thu May 14 14:05:07 EDT 2009


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090514/9bc6a245/attachment-0001.htm 


More information about the dojo-contributors mailing list