[dojo-contributors] dojo roadmap

Nathan Toone toonetown at dojotoolkit.org
Thu May 14 13:34:34 EDT 2009


I tend to agree here - I, personally in the projects I use, have no  
use of gfx...and would prefer not to have the bloat of having it in  
dojo core.

I think that it goes back to what Mike said about download  
tracking...although *we* may think that gfx is cool...we aren't the  
ones actually out there using it - and we should probably do some  
download tracking on it before we actually promote anything.  If  
downloads of the gfx "plugin" or "extension" (or whatever we want to  
call it) are near the number of downloads for the core dojo release,  
then we include it...but not until then.

-Nathan

On May 14, 2009, at 11:26 AM, 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2433 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090514/f765afa4/attachment-0001.p7s 


More information about the dojo-contributors mailing list