[dojo-contributors] response to Tom's proposal

Sun Dec 10 21:46:40 EST 2006

Good thing I consider this a draft; I think that maybe some of my wording
needs to change, because between you and Owen, it's obvious some of my
points are not coming across properly.

Specifically, on the idea of a full-on rewrite...if it turns out it isn't
necessary then we won't need to do a full-on rewrite.  I'm suggesting that
it's not out of the question, that we should consider the option
objectively--and if it turns out that it would be easier and better to start
from the ground up, we should.  But that doesn't mean we have to, if we
don't need to.

Second, I'm not proposing a second full-on widget system.  I'm proposing
something that facilitates custom development.  I know where you're coming
from on this one Dylan but I remember what it took for me to figure out how
to create a widget from scratch--and I can only imagine what it might be
like for someone else.  Then I remember the approach that I took with the
charting engine--where I ask for a single node and apply the chart to
it--and notice major speed differences, simply because I didn't use the
widget engine...and I wonder why I can't do the same with other things.
Yes, there's been performance gains but there's also been a lot of extra
functionality thrown in, and one seems to offset the other at times.

Plus there's been the lack of testing with large amounts of widgets in the
same page but that's a different topic for a different time, I think.

The most controversial topic will be the sub-project split off.  I'm not
advocating creating new full on projects, each with its own version and
release schedule (though we could if we really wanted to, and I think the
widget system would be a prime candidate).  I'm talking about pushing things
out of the dojo namespace and into thier own--in other words, I'm talking
about creating the *perception* of separated modules.  There's a big
difference...what I'm taking aim at here is the attempt and attitude (yes,
mostly by you and I am sorry we disagree on this point) that *everything*
useful be a part of the Dojo Toolkit.  I think this is a bad idea, mostly
because I don't think we need to be so inclusive.  Why should we force
people to contribute things back to the toolkit instead of letting them
release it on thier own?  If they want to contribute it, that's fine--but we
need to weigh the usefulness of things with the "official" distribution.
Again, the widget system is a great example: if I wanted to personally
create a different system (I don't) and contribute it back, would you take
it?  Or do we want to continue to say there's only one "official" way to
skin a cat?

Think about what I'm talking about here though.  Imagine a small
dojo.jsincluding the very basics of what almost every application is
built on, as a
pre-built, available thing.  Call that the core, and distribute it as such.
Then think about including that as a part of a custom profile build, if you
want to.  Think "incremental" build...

Lastly, I pick on the build system because it is by far the most
hodgepodge--and visible--of all the tools we have, and I know we can do a
much better job of planning it out.  What I'm suggesting here is not to
throw out the current build system before its time, but to encourage the
development efforts of a much more self-contained system--such as the one
Bryan has begun in pure Python.

In the end, I'm not actually suggesting radical changes at all--I'm
projecting what I see as the natural evolution of what we've done with the
toolkit, and where I think we're going to end up with it.  Really, if I
suggest anything, it's that we should start removing some of the extra code
and streamline an awful lot of what we have already.

trt

On 12/10/06, Dylan Schiemann <mail at dylans.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> http://dojo.jot.com/WikiHome/Widgets2.0/DylansResponseToTomsProposal
>
> I think I wrote more in response to Tom than I originally wrote for my
> musings... I think I agree with about half of what Tom said, so this
> emphasizes the things where I disagree.
>
> Owen Williams wrote:
> >
> > Responses to Tom's full-on-proposal:
> >
> http://dojo.jot.com/WikiHome/Widgets2.0/The%20full-on%20TRT%20proposal%20%28a%20bit%20more%20than%20you%20probably%20expected%29
> >
> > Firstly, Tom, thank for taking the time to write such a coherent
> > proposal.  I agree with much of it, particularly the parts about needing
> > to improve the build process and communication.
> >
> >
> > Some questions/thoughts:
> >
> > 1) It seems to me that many if not all of the widgets in the "current
> > widgets" (1.0) will be necessary when developing in the "new style"
> > (2.0).  Web 2.0 applications still have trees, lists, grids, etc.  I can
> > see what you talk about with the different audiences, but it seems like
> > having two completely different widget systems will result in a lot of
> > overlap and duplication of code.  And what if I'm using the "2.0"
> > system, but I need something that's only in the "1.0" set?   I'll have
> > to pull a lot of "1.0" infrastructure in just to handle that one widget
> > -- Yuck!  Or build it myself, when it's right there on the other side of
> > the wall -- double Yuck!
> >
> > 2) I'm not sure that the "1.0" widget users are more concerned about
> > speed of development than runtime performance.  Especially if folks are
> > coming from the Java world, they are used to writing lots of code.  I
> > see this all the time at Zimbra -- I've been trying to lead that team
> > into a more declarative style of programming, and the answer I keep
> > hearing is that they understand the (very Java-ish) way of programming
> > they're doing now, that it's fast enough, that they'd rather have things
> > be done more explicitly (meaning more code) than have a system that dots
> > the i's and crosses the t's for them automatically that they don't
> > understand.
> >
> > 3) I'm not sure that splitting things up into separate sub-projects will
> > help make things less confusing overall.  I see the benefits for
> > discouraging cross-contamination and build sickness that you mention.
> > However, with things like data binding for widgets (whether in the 1.0
> > or 2.0, and I think it applies in both) -- how would you structure this
> > as two separate sub-projects?  Does pulling in the data binding stuff
> > also add functionality to the 1.0 widget set?
> >
> > 4)  When I think of a "toolkit" in the real world, I definitely think of
> > discrete components (wrenches, saws, etc).  It seems like Dojo in this
> > sense is the "brand" (like DeWalt or Black & Decker).  I would hope that
> > in whatever structure we end up with, we stay with the Dojo "brand" over
> > all the projects.   I think one of the biggest disadvantages of the
> > Prototype-based system of development that I can see is that to use it,
> > I have to go to at least three different development sites and learn how
> > they do things, how their documentation works, etc.
> >
> >
> >
> > About the docs and API ref -- I'd love to have your opinions on the
> > following.  I'm genuinely curious and am not taking this
> personally.  :-)
> >
> > a) One thing that may not be apparent is that the entire Api application
> > is itself completely usable offline if you have a dojo install.  You can
> > hit  file://your/dojo/install/api/index.html and it will present all of
> > the info in exactly the same way as it does online.  One thing that
> > we're not currently doing (but could pretty easily be done) is making
> > sure that the /docscripts/local/json/* files are updated when the builds
> > are done -- this just involves running the docscripts and checking in
> > the output before the builds are cut.  This, IMO, is one of the main
> > reasons why a hybrid generated/wiki'd docs would not work -- there would
> > be no way to work on it offline.
> >
> > b) You call for an indexed PDF as doc -- how would this be structured in
> > your mind?  Is this the API ref, or the Book, or both?  What benefits
> > (other than printing, see below) would this have over the current API
> > ref?  Would you see this being built off of the parsed comments, some
> > other means, ???
> >
> > c) Printing is definitely not facilitated now, but could easily be done
> > -- it's mostly just a matter of expanding all of the visible sections
> > and opening in a new window optimized for printing.
> >
> > d) You said "The current API tool is OK for what it does but may need to
> > be reassessed at some point."  What are you thinking it should do?  How
> > would you change it?  What would you add or take away?
> >
> > Frankly, I'm running out of steam on the entire doc portion of the house
> > -- I've really only been working on this because Alex asked me to step
> > in last August to get something done in the 0.4 timeframe.  I could use
> > help in bringing some of the features that we've been discussing to
> > term.  I'd love to turn the "ownership" of the docs portion of the code
> > over to someone else so I can concentrate on parts of the system that
> > are more fun for me.
> >
> > cheers
> > Owen
> > -------------------------
> > Whenever I despair, I remember that the way of truth and love has always
> > won. There may be tyrants and murderers, and for a time, they may seem
> > invincible, but in the end, they always fail. Think of it: always.  --
> > Mohandas K. Ghandi
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at dojotoolkit.org
> > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFfLxY8nLgh/JJsxERAg7IAJ4jW9zmBScoZQUM+I9cfF4M4rO4BwCeKEa5
> thZV002g0MBkNY2M01caM0U=
> =PvVB
> -----END PGP SIGNATURE-----
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20061210/6525a0d4/attachment.htm 