See ChangeLog

Monotone-Parent: 1e01e7055612c8aa2f2c0e9151035ef348604b8e Monotone-Revision: ab8b4a7a66ffdb6688f466f2cc301caf1fc40a66 Monotone-Author: ludovic@Sophos.ca Monotone-Date: 2010-09-24T19:13:02 Monotone-Branch: ca.inverse.sogo
2026-07-08 01:45:08 +00:00 · 2010-09-24 19:13:02 +00:00
parent 38af9bc66b
commit 3d2f08f678
25 changed files with 1 additions and 1485 deletions
@@ -1,117 +0,0 @@
-Storage Backend
-===============
-
-The storage backend implements the "low level" folder abstraction, which is
-basically an arbitary "BLOB" containing some document. The feature is that
-we extract "quick access" / "searchable" attributes from the document content.
-
-Further it contains the "folder management" API, as named folders can be stored
-in different databases.
-Note: we need a way to tell where "new" folders should be created
-Note: to sync with LDAP we need to periodically delete or archive old folders
-
-Folders have associated a type (like 'calendar') which defines the query
-attributes and serialization format.
-
-TODO
-====
- fix some OCS naming
-  - defaults
-  - lookup directories
- hierarchies deeper than 4 (properly filter on path in OCS)
-
-Open Questions
-==============
-
-System-meta-data in the blob-table or in the quick-table?
- master data belongs into the blob table
- could be regular 'NSxxx' keys to differentiate meta data from
-
-Class Hierarchy
-===============
-
-  [NSObject]
-    OCSContext                  - tracking context
-    OCSFolder                   - represents a single folder
-    OCSFolderManager            - manages folders
-    OCSFolderType               - the mapping info for a specific folder-type
-    OCSFieldInfo                - mapping info for one 'quick field'
-    OCSChannelManager           - maintains EOAdaptorChannel objects
-
-  TBD:
-  - field 'extractor'
-  - field 'value' (eg array values for participants?)
-  - BLOB archiver/unarchiver
-
-Defaults
-========
-
-  OCSFolderInfoURL - the DB URL where the folder-info table is located
-    eg: http://OGo:OGo@localhost/test/folder_info
-
-  OCSFolderManagerDebugEnabled      - enable folder-manager debug logs
-  OCSFolderManagerSQLDebugEnabled   - enable folder-manager SQL gen debug logs
-
-  OCSChannelManagerDebugEnabled     - enable channel debug pooling logs
-  OCSChannelManagerPoolDebugEnabled - debug pool handle allocation
-  
-  OCSChannelExpireAge       - if that age in seconds is exceeded, a channel 
-                              will be removed from the pool
-  OCSChannelCollectionTimer - time in seconds. each n-seconds the pool will be
-			      checked for channels too old
-  
-  [PGDebugEnabled] - enable PostgreSQL adaptor debugging
-
-URLs
-====
-
-  "Database URLs"
-  
-  We use the schema:
-    postgresql://[user]:[password]@[host]:[port]/[dbname]/[tablename]
-
-Support Tools
-=============
-
- tools we need:
-  - one to recreate a quick table based on the blob table
-
-Notes
-=====
-
- need to use http:// URLs for connect info, until generic URLs in 
-  libFoundation are fixed (the parses breaks on the login/password parts)
-
-QA
-==
-
-Q: Why do we use two tables, we could store the quick columns in the blob?
-==
-They could be in the same table. We considered using separate tables since the 
-quick table is likely to be recreated now and then if BLOB indexing 
-requirements change.
-Actually one could even use different _quick tables which share a common BLOB 
-table.
-(a quick table is nothing more than a database index and like with DB indexes 
- multiple ones for different requirements can make sense).
-
-Further it might improve caching behaviour for row based caches (the quick 
-table is going to be queried much more often) - not sure whether this is 
-relevant with PostgreSQL, probably not?
-
-Q: Can we use a VARCHAR primary key?
-==
-We asked in the postgres IRC channel and apparently the performance penalty of
-string primary keys isn't big.
-We could also use an 'internal' int sequence in addition (might be useful for
-supporting ZideLook)
-Motivation: the 'iCalendar' ID is a string and usually looks like a GUID.
-
-Q: Why using VARCHAR instead of TEXT in the BLOB?
-==
-To quote PostgreSQL documentation:
-"There are no performance differences between these three types, apart from 
- the increased storage size when using the blank-padded type."
-So varchar(xx) is just a large TEXT. Since we intend to store mostly small
-snippets of data (tiny XML fragments), we considered VARCHAR the more 
-appropriate type.