Changes between Version 38 and Version 39 of GenericTrac

Timestamp:

Oct 1, 2010, 8:55:28 PM (14 years ago)

Author:

Christian Boos

Comment:

start rewriting the page to give better indications of the intent and more concrete directions

GenericTrac

@@ -2 +2 @@
 
 This page defines a new data model for Trac that should be suitable
-for storing most of the data from resources, along with their change history.
-
-In the longer term, it would be more appropriate to keep the change history in a dedicated system (a version control backend, even a [DistributedTrac distributed] one).
-In that picture, we could even provide a simple "dbvcs" backend, which would use the database for storing the change history much like we do now.
-
-The main benefits expected from the new model are:
+for manipulating and storing most of the data from resources, 
+along with their change history.
+
+There are effectively two parts to this proposal:
+ - the API level, how resource data is presented to the program
+ - the storage level, how the resource data are stored on persistent memory
+
+The high level API is intended to unify and take the best aspects of the different model used so far (!WikiPage, Ticket, Milestone, etc.). Actually, only the Ticket is really flexible and nice, the others are just simpler and much more limited models, so it's rather an "embrace and extend" move from the Ticket model to the others...
+
+While the high level API tends to unify things, the low level API will be there to introduce some diversity in the storage, at best transparent to the "user" of the higher level API. Those different storage models could be different table layouts in the database, but also in the longer term, different or complementary storage backend. It would be more appropriate to keep the change history in a dedicated system, like a version control backend, even a [DistributedTrac distributed] one).
+
+The main benefits expected from the new API are:
  - simplification of the internals of Trac, especially for the ticket model,
    in which the storage of changes is quite cumbersome (see #454, #6466)