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.
I did some coding experiments (an old trac-object branch, the xref
branch) but it never went far. But I kept going and thinking about this,
and now 5 years later, it looks like most aspects are crystallizing, so
we might finally see something emerge from this vaporware ;-)
I fully agree that a kind of operational summary of these ideas is now
needed, but the usual disclaimer applies: time is scarse, and pressing
bugs, new cool features and patches keep flowing in the project
meanwhile...
With this in mind, let me give you some (beginning of) answers.
On 10/1/2010 4:08 PM, Itamar O wrote:
As the subject suggests, I am going to try to discuss several gigantic
topics in Trac development.
So brace yourselves ;-) (or abandon now)
The root for this discussion is my need for richer user management in
Trac (http://trac.edgewall.org/ticket/2456#comment:49),
and Christian's reply that this should go into core, but employ
GenericTrac (http://trac.edgewall.org/wiki/GenericTrac) instead of yet
another model.
I have spent a good part of the time since then looking into tons of
wiki pages and tickets related to the topics mentioned in the subject
(about 60 open tabs... good thing I have tab-kit for Firefox), that
seem to be very inter-related to one another, and ended up with lots
of insights and ideas, but also with much confusion as to how to proceed.
It seems the current focus is on the ticket subsystem, from several
leads. That would be one starting point, as this is also the most
complex situation, so if handled successfully, all the rest could follow
easily. But that's only one possible start, as hinted in the GenericTrac
page.
From the GenericTrac page it is not clear whether the concept is still
being designed and actively discussed, or completed the design phase,
and if implementation has begun somewhere (trunk / experimental branch
/ ..).
Still designing, but now I'm *really* close to get started, and the fact
that you seem interested is just another "trigger" for me.
Bottom line - what should I do in order to jump in and make it happen??
Say you just did ;-)
Furthermore, the details on the GenericTrac page are pretty focused on
DB schema design, while I was also expecting details on a generic
object model.
This generic object model is mentioned in
http://trac.edgewall.org/wiki/TracDev/Proposals/DataModel (which
refers the reader back to GenericTrac), and also in
http://trac.edgewall.org/wiki/TracObjectModelProposal (suggestions for
a term for a "facet" of a TracObject: aspect, view, trait, descriptor).
It's a little spaghetti-docs, so it's hard to tell which is the
authoritative source on the subject, and the same questions as raised
concerning GenericTrac apply here as well (state of design /
discussion, state of implementation, pointer if I want to join).
The main ideas about the API is even not yet written down. In short, I
think about representing the data for the resources using an immutable
View object behaving like a read-only dict, which can also be used for
caching. Then we'd have a model object which would wrap this immutable
view (think about the ._old dict) and store changes in a mutable dict. A
store delegate would take care of dumping the changes to the database
(or elsewhere -> #1132).
Considerations of multi-project support are intertwined throughout the
previous 3 major topics, and I couldn't agree more that introducing
GenericTrac and a unified generic ObjectModel is an excellent chance
to apply multi-project considerations. Unfortunately - this makes the
task even scarier in size than it's already is, which contribute to
feelings of confusion and disorientation I experience (I'm certain
that if it wasn't a holiday here, and I wasn't looking for excuses to
avoid working on my thesis-research, I would never make it this far in
digging into the docs and code).
I've started to experiment about "object" relations when working on the
#31 topic (ticket-links branch on t.e.o), and as I currently see it, the
relations would be better kept as properties on the dependent object
(i.e. a ticket would have a "project" property linking to the id of the
project resource).
I think what should help in moving this forward is:
- A coherent description of the state of things today (my questions above)
- Some organization in the docs to avoid the spaghetti-sensation I
experienced
- An operative plan to implement the generic DB-schema and
ObjectModel, that is clear enough to supply pointers to contributors
who are interested in working on this (for example, I'm interested in
working on user management, and am willing to do extra in order to
make the generic stuff happen).
If such a plan doesn't already exist in some way or another, I guess
this is an opportunity to form that plan and discuss it.
It's all open. We could develop that here on Trac-Dev, or on a Wiki
page. But what is really needed is to get started coding, as only this
can validate or invalidate the assumptions I made in those various notes.
I think that, ultimately, there should be the following resources on
t.e.o to track this endeavor:
- Proposal-wiki-pages describing the *chosen* design of: Generic DB
schema, Generic object model, Multi-project support (with historical
ideas, discussions and brainstorming conveniently hidden in sub-wiki's
under these proposals (or better yet, if it existed - another "facet",
like discussions, or brainstorming)).
- A dedicated milestone ("Generic Trac") with the operative plan as
its description.
- Assigning existing relevant tickets to this milestone, and creating
new relevant tickets under this milestone.
there are really lots of tickets that are relevant, so it might be
useful to select a handful as leading use-cases and include them in
the above operative plan.
Well, yes, there are lots of tickets about this. I don't think moving
those to a new milestone is a good idea. Better use keywords. Most of
the relevant tickets already have the tracobject keyword, we could use
the generic keyword to tag those which can be used to bootstrap the effort.
The GenericTrac page can be used for the chosen design, but for now
there's nothing "chosen", we need to experiment first.
And maybe what is needed to get a good overview and summary is just
*another point of view* (hint, hint).
I'll finish with a little off-topic remark on the method of discussing
proposals:
if I read the wiki correctly, it appears that discussions took place
directly within the wiki, by editing the content.
this seems somewhat uncomfortable as compared to mailing list threads
or ticket comments,
since I don't get notifications for wiki-updates (no cc on wiki's),
and it's not as trivial to track who changed what and why.
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.
don't read this as a complaint, but as a use-case for the generic
object model, combined with the tabbed views concept (e.g. wiki's
should also have cc-fields, and a discussion view (facet? :-) ), that
can exist "behind" the "current content").
so, thanks for reading up to here,
and I hope this will help make stuff happen!
That would be a pleasure!
(there are numerous multi-year-old defects and enhancements that can
be solved if we do this right!)
I'm glad you realize that, as this is the whole point of the exercise.
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
