On 10/1/2010 9:47 PM, osimons wrote:
On Oct 1, 5:16 pm, Christian Boos<cb...@neuf.fr> wrote:
Hello Itamar,
Thanks for your interest on the topic. Let me shed some light on this.
First, some apologies for the "spaghetti" aspect, it's really because
this is all about notes which have been taken sporadically and ideas
which have evolved for now about 5 years, all starting in the
TracObjectModelProposal and consolidated during my practice of
maintaining Trac.
[...major snip...]
For the edits on the wiki, It's easy: they were mainly written by me ;-)
The discussion on Trac-Dev could never happen so far, as it was
"trolled" many times by comments like "-1", "this is a bad idea" and the
like. I think this won't happen again, as the people behind those
comments have not contributed anything to the project in years and it
would be very bold from them to just jump in now to try to derail this
effort. You never know, but if this happens, just ignore it. What we
need is a rationale development discussion, just as it often happen on
tickets, not hand waving.
Well, trolling... :-) It was never like that, but more that some of us
do prefer the loosely coupled and explicit nature of objects calling
each other with simple arguments to get work done. I, like many
others, came into Trac because the simplicity of the Trac internals. I
made plugins because they were easy, powerful and flexible.
GenericTrac is a new "Framework" to be grafted into this structure,
and it is not like a strong case has been made so far for it being a
better way of doing things?
Your whole mail is on the premise that Trac is "simple" and that this
horribly "complex framework" is going to end this. Well, reality is a
bit different. Over the years, the Trac code base grew into something
quite complex (not overly complex, otherwise I wouldn't hang around),
and from time to time you need to take action to make things simple
*again*. The fact that from the start each submodule had a different API
and table layout to do approximately the same thing certainly
contributed to spread that complexity (and we're talking about
gratuitous differences here, not differences because of carefully made
design choices).
On the advice of Itamar, I've started to rewrite the GenericTrac
documentation into some kind of sensible plan, backed with code. This
won't happen overnight but I'm working on it. The hope is that the code
will speak for itself, it will be on the same level of complexity as the
Ticket is today, minus the quirks (like, how we grafted much
"non-relational" information in the ticket_change table).
This "different" is fine until you need to really understand it. I
contribute to Trac, but what I mainly do is mainly plugins. You and
Remy are almost completely dedicated to core code (which is great of
course), but I feel this "different" apect in ways you don't.
1. Complex classes. [...]
"Flat is better than nested."
2. Complex classes. As a plugin developer I appreciate the fact that
the internals are managed by me.
It depends on the plugin, I imagine. A lot of plugins simply try to get
around the limitations of the core system. And a lot of the complexity
of the plugins comes from the fact that the Trac internal data model is
overly complex (ticket_change anyone?). Some plugins add their own
subsystems, and there maybe it's better to stay in control, maybe it's
better to benefit from more infrastructure support. I guess it all
depends on the convenience level of the infrastructure and the degree of
specificity of the subsystem.
"Simple is better than complex."
Amen.
2. Complex classes. [snip]
"Explicit is better than implicit."
3. Optional complex classes. [re-snip]
"There should be one-- and preferably only one --obvious way to do
it."
Five years as you say, and noone really understands what it means or
involves to get it done or how exactly it will make things better...
Well, five years of me maintaining Trac, seeing all the features people
want out of it, the bugs and the quirks in the code, I can tell you I
have an idea or two how we could *improve* things. I also sometimes look
at what exists outside of Trac (really, this happens sometimes!), and I
see that we missed quite a few opportunities of not starting this effort
earlier. But well, it's not too late, 0.13, 0.14, 0.15 and 0.16 in 2
years scope, I can assure you that people will come back ;-)
I did hope that the original page (TracObjectModelProposal) would have
spoken for itself and that people would simply understand what it would
take to achieve this vision and join me to make this happen, solving the
technical details one by one. This indeed didn't really happen.
"Sparse is better than dense."
I've stayed with the project for a long time, and I'm planning to stay
on. I'll respect the direction the majority want to take, and as you
also said it is really only fair that when you write the code you have
much more important say in what should be done and how. I have no
problem with that. I do however want to use my voice to express my
concerns about this direction.
See, *my* concern is that instead of discussing in a constructive way
about the practical problems the Trac code base has, and its possible
solutions, you come now with very high-level software engineering
advices, which feels a bit out of place. Thanks, but I do also read
occasionally, and in general, yes I prefer code that's easy to
understand and maintain. Especially given the fact that *I* maintain
that damn code base (not alone of course, but a good deal of it), and I
feel the pressing need for this simplification.
So I really think the kind of philosophical discussion you started leads
nowhere. We need experiments, testing, people pointing shortcomings,
suggesting better APIs, improved datamodels, smarter ways of caching,
this sort of things. And at *that* level, feel free to exercise your
software engineering knowledge, there it will be useful and you know I'm
always open to suggestions, advices and *better* ideas than mine.
As Rémy said, maybe it's now time for some code...
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-...@googlegroups.com.
To unsubscribe from this group, send email to
trac-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
