On Oct 6, 11:03 pm, "Mikael Relbe" <[email protected]> wrote: > Dear Trac developers, especially Christian (cboos) and Simon (osimons) > > The discussion in ticket #6492 about timeline icons [1] has taken a > different turn than I expected, and I am afraid that my last comment, > comment:35, may be interpreted as I am not interested in the refactoring > problem. > > I am writing here (instead of cluttering up the ticket even more) that this > is not the case. I do understand, and appreciate, the concerns raised by > Simon in comment:23. > > My intention (which was stated in comment:32 but perhaps lost in the debate) > is that the discussion about this should perhaps be moved to another ticket. > > However, we can of course not ignore the fact about the refactoring "issue", > which I feel makes my proposal, concerning the timeline icons, problematic > to handle. > > Simon proposed that I change the implementation to start with (comment:23), > instead of refactoring the timeline event interface. I can understand that. > However, I want to add more logics to the timeline module, which will > require even more changes (highlighting ticket ownership, for instance). > Each such change will require yet more tweaking of the tuples. > > I see two possible scenarios for the development here, which I would like to > discuss: > > 1. First we accept Simons proposal, by "reverting" the refactoring of the > timeline interface made in the patches that I have supplied so far. > Thereafter we re-factor the timeline event interface (coordinated by a > separate ticket). > > 2. The opposite: first re-factor the timeline event interface (coordinated > by separate ticket), then a re-make of the timeline icons proposal. > > I am willing to do either, for me it's important that we agree on which > should come first, and that we think the functionality, demonstrated by the > patches I presented in comment:27, makes sense and are wished for. > > What's your opinion? > > Sincerely Yours > Mikael Relbe (mrelbe) > > _1: > <http://trac.edgewall.org/ticket/6492>http://trac.edgewall.org/ticket/6492
Hi Mikael, and thanks for opening this thread. I did mean to do the same - and have since stopped cluttering up your ticket with its pretty icons :-) The discussion on the ticket turned out to be a bit "deeper" than expected. And certainly for Timeline that have an API that, in my opinion, have been broken more or less forever by entangling the "data" aspect of timeline events by their "presentation" (rendering). As mentioned, the issue arise from other needs, in particular the TracRPC (XmlPrcPlugin) that really should support proper Timeline information. But the output I get by looking at the events (html) is not something I can pass on to machine-interface clients that I know absolutely nothing about. Nor can I assume anything about the data and try to fix it. Other than then the 'kind' that is currently used as visual style class to make the icon, there is no underlying data or domain knowledge to be found by querying the Timeline API. I will not hard-code a mapping for core modules + any possible external plugin that may provide Timeline events. So, I'm frustrated. How should it work? The Events API should provide pure event data - the 'when', 'who' and 'what'. I'm +1 on adding the 'action' as you suggest, that helps to understand the 'what'. However, I would really want it to at least include the resource which would provide the unique identification of the data as well as a means of getting its title and description (via the Resource API). Then the resource could perhaps be asked to render its transitional and finite state by various methods at Resource level (and of course the actual implementation by the provider of the resource realm). I see there is general positivity for an API change that changes all this to just return some 'fluffy' Event object with all stuff attached to it - "yield event". It certainly makes it a lot easier to attach all kinds of new data and meaning onto such an object over time (easily exendible), but personally I think that is bad API design as it tells the consumer nothing about what to expect and the provider nothing about what to deliver. How would you make breaking changes? By adding various magic to the Event object to discover if its state of data and methods is 'OK' according to the current executing visual experience of the Trac TimelineModule? If I got a TimelineRPC implementation off the ground, what can I expect to assume when my code is to run on various versions of Trac and against a multitude of plugins (also at varying versions) that yield such event objects? APIs should break when there are new and better ways, and the breakage should be obvious to see and obvious to debug. It will be a pain to debug a yielded half-implemented event that crashes rendering at a much later, disconnected, stage. Instead of just raising an exception right at the initial call to fetch the event when things do not match up. Anyway, my proposal was to not break the API until we had a clear idea of how the API should be broken and what the new API should be and look like. That is why I looked at a simple and non-obtrusive fix for adding 'action' to support the improved icons. The Event object suggestion is a breaking change - as opposed to just gaining an (optional) feature. When redefining the API in such a way, we need at some point to deprecate the old interface. However, I'm not so sure the underlying assumptions of the Timeline code is worth changing at this point - too much is vested into the entangled structure. It is perhaps best if I left it alone, and instead pursued other ways of providing such a lower-level data interface. :::simon -- 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.
