amorfo77/sogo
1
0
Fork 0
mirror of https://github.com/inverse-inc/sogo.git synced 2026-07-08 09:55:09 +00:00
Code Issues Projects Releases Wiki Activity

See ChangeLog

Browse Source 
Monotone-Parent: 1e01e7055612c8aa2f2c0e9151035ef348604b8e
Monotone-Revision: ab8b4a7a66ffdb6688f466f2cc301caf1fc40a66

Monotone-Author: ludovic@Sophos.ca
Monotone-Date: 2010-09-24T19:13:02
Monotone-Branch: ca.inverse.sogo
This commit is contained in:
Ludovic Marcotte
2010-09-24 19:13:02 +00:00
parent 38af9bc66b
commit 3d2f08f678
25 changed files with 1 additions and 1485 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SOPE/GDLContentStore/README
-117
View File
@@ -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.
SOPE/NGCards/README
-19
View File
@@ -1,19 +0,0 @@
TODO: improve text
Objective-C classes for representing iCalendar entities as objects. To
actually parse iCalendar entities the sope-xml versitSaxDriver is used.
Note that this library doesn't make any use of the now deprecated libical but
rather relies on the SAX interface (SaxObjectDecoder is used).
Recurrences
===========
Recurrences are modeled via iCalRecurrenceRules and an iCalRecurrenceCalculator
which contains all the necessary logic according to RFC2445 to interpret
iCalRecurrenceRules. The calculator needs a referrence date for the first
instance of a recurrence which is usually provided by any of the repeatable
entity objects (i.e. iCalEvent).
Please note that recurrences are work in progress and far from being
complete/compliant with RFC2445. So far only the most simple cases are done
properly.
SOPE/NGCards/samples/README
-9
View File
@@ -1,9 +0,0 @@
sope-ical/samples
This directory contains sample programs for the sope-ical libraries.
Tools
=====
ical2 - uses SaxObjectDecoder with NGiCal.xmap
ical3 - uses iCalDataSource to run queries on iCal files
SOPE/NGCards/tests/README
-8
View File
@@ -1,8 +0,0 @@
This folder contains unit tests for the NGiCal project.
It uses SEN:TE's OCUnit project which can be found at
http://www.sente.ch/software/ocunit/
I used OCUnitRoot v38, later versions might work as well.
NOTE: This is currently provided in Xcode only.
SOPE/NGCards/versitCardsSaxDriver/README
-53
View File
@@ -1,53 +0,0 @@
Overview
========
Two SaxObjC drivers for iCalendar and vCard files, initially written by
Max Berger <max@berger.name>.
VSiCalSaxDriver basically maps iCal 2.0 components, properties and parameters
to the XML events according to the xCal 02 draft (iCal 3.0).
Having a SAX driver for iCal might seem strange and a bit inefficient at
first look, but the time saved for the application-level developer is
significant, since he only needs to learn (or usually already knows) the
SAX or DOM APIs and any XML API based on them (like XPATH, XQUERY).
The VSiCalSaxDriver is aimed to be a replacement for the older (but better
tested as of now) iCalSaxDriver. However, the iCalSaxDriver depends on the
abandoned and hardly maintainable libical, which itself is an additional
dependency to the OGo project and thus a welcome candidate for replacement.
The VSSaxDriver attempts to follow RFC2445 closely, however the parser is
written to be robust when it comes to parsing real life content. Currently,
unescaping is done for more characters then it MUST according to RFC2445, but
this is probably not a bad idea - wrongly escaped characters will still be
parsed according to the original intent. Also, the VSSaxDriver supports Unix
style terminated lines/folding.
ToDo
====
- improve error handling (SaxExceptions !)
- make the driver fully xCal compliant
Defaults
========
Name Type Description
------------------------------------------------------------------------------
VSSaxDriverDebugEnabled BOOL YES -> log some debug information
via NSLog
Examples
========
To "convert" an iCalendar to xCal (the test programs print out some XML):
saxxml -XMLReader VSiCalSaxDriver test1.ics
domxml -XMLReader VSiCalSaxDriver -xml test1.ics
To "convert" an iCalendar to PYX:
domxml -XMLReader VSiCalSaxDriver -pyx test1.ics