Modify

Opened 19 months ago

Last modified 19 months ago

#11117 new enhancement

Notes about T1 RA branch

Reported by: makadev Owned by: makadev
Priority: normal Component: ProjectPlanPlugin
Severity: normal Keywords:
Cc: Trac Release: 1.0

Description

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

Attachments (0)

Change History (1)

comment:1 Changed 19 months ago by makadev

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

Add Comment

Modify Ticket

Action
as new The owner will remain makadev.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.