Notes about T1 RA branch

[Matthias]

T1RA Branch Notes and Ideas:

This branch is for testing, fixing and re-engineering. It is not intended for productive use and may be deleted in future. Changes may be merged with the 0.11 (0.11/0.12) trunk or pushed into a new (1.0+) trunk if compatibility can't be established.

Notes and Ideas:

• T1 Trac 1.0 (and Python 2.7+) compatibility and features
  • Use Babel which is part of Trac 1.0 (i18n support)
    • dynamic check and load, this may be wrapable for backward compatibility
  • LC settings usage where applicable
    • Read out default Time/Date formats and Locale
    • propagate for javascript pieces
  • check SQL stats which use (transaction) db pointers
    • Trac 1.0 deprecated this in favor of transaction pooling (see trac.db.pool / trac.env.get_db_cnx and so on in trac 1.0 stable branch)
    • replace with transactions
    • replace read only access with get_read_db and similar
    • may need to layer this for backward compatibility
  • more to check

• R Review and Rewrite
  • pin down todo's and fix-me's in code
  • pin down performance killers
    • Import *
    • make use of all
    • check where immutable's (especially replacement for dicts/lists) are applicable
  • pin down hacks and magics introduced in bugfixes and fast compatibility changes
  • check permission checks
  • add unittest where applicable
  • additionally: whatever comes to mind while reading

• A Architecture checks and remodeling
  • clean and/or rewrite the (old) ppfilter,ppextensions mess
    • ppfilter was intended/invented as a (ticket) query system on top of tracs (report) query engine for compatibility with future versions (and SQL dialects). It introduces some problems thought, especially for cross-plugin support (plugins with own tables), big systems with lots of tickets and custom queries which are not implemented. ppfilter should be hidden or replaced by a simple query language on top of the ticket or trac db model system
    • check for an architecture for cross-plugin compatibility and capabilities
      • simple layer
      • extendible (with plugins that shall be used as backbone model for content)
        • mapping time-stamp formats, fields and tables *time stamps should be used in numeric (f.e. msec) format for checks and so on, also javascript can handle msecs easily (check locale)
          • dependencies may be inter-trac or otherwise non-standard (no ticket id's)
          • may need to hook into TicketSystem (ITicket* extension point[s]) for keeping usable data
          • may need a conversion method for switching systems
        • coup with different semantics of the fields (e.g. mastertickets blocking/blockedby vs. ppps dependencies, child tickets and so on) and formats
        • candidates (time/dependency) ​http://trac.edgewall.org/wiki/PluginList in category Project Time Management / Ticket System Extensions
    • ppextensions is mostly unused and may be moved/integrated into the renderers which use it (dependency oriented reports/gv renderer)
  • extending ppservice, keep code path short: ppservice is a core provider for data, it must be fast but also capable of providing mostly any data (queried/filtered, trac internals like custom fields, cross-plugin fields, locale of the current view, ...?) such that the renderer architecture is also applicable in javascript (workload shift from host to client, allow better and generic usage of data for javascript renderers/reports/..)
  • ppconfig: separate the abstract model from data (class declarations/actual config items), try to load config items ondemand instead of loading all data configs+default values, integrate babel support
  • pprender: try to merge the new/old renderers back together, use per "renderer type" modules like currently used in renderer subpackage and load all needed modules on demand (e.g. gvproto for)
  • ppenv: check and rewrite as needed
  • ppcache: check and rewrite as needed

[Matthias]

(In [13232]) Branch for trac 1.0 compatibility, features and general ideas (see #11117)