err.no Git - scalable-opengroupware.org/blob - dbd/README

   1 # $Id$
   2
   3 PostgreSQL Browser
   4 ==================
   5
   6 Intention:
   7 - fix open SOPE issues
   8 - fix PostgreSQL issues, prepare low-level storage
   9 - work towards SOGo from a storage point of view (with UI-X coming down from a
  10   UI point of view)
  11
  12 SOPE Hierarchy
  13 - /DBHOST/Databases/MYDB/MYTABLE/MYFIELD
  14 - /DBHOST/Users/MYUSER
  15
  16 Class Hierarchy
  17   DSoObject
  18     DSoHost            "DBHOST"
  19     DSoTable           "MYTABLE"
  20     DSoDatabase        "MYDB"
  21     DSoDatabaseManager "Database"
  22     DSoUser            "MYUSER"
  23     DSoUserManager     "Users"
  24     DSoField           "MYFIELD"
  25
  26 Tricks used
  27 ===========
  28
  29 - *always* remember that SOPE objects which are looked up in the traversal
  30   process are conceptually *UI* objects, not datamodel objects (though this
  31   might be done for simplistic applications)
  32   - the idea is: the URL is UI
  33
  34 - small hack in MainPage.m to make a redirect to a "valid" WO URL if the
  35   request-handler-key is missing
  36   - should be made by SOPE itself?
  37
  38 - own authenticator object
  39   - two different authenticators (with dbname available and without)
  40
  41 - a hack in the SoApplication -lookupName: to differentiate between
  42   'hostnames' and resources
  43
  44 - in DSoObject we extract login/password from the basic auth
  45   - SOPE does all the authentication for SOPE level objects, but if we
  46     want to reuse passwords, we need to do that manually
  47   - we reuse an HTTP parsing method from SoHTTPAuthenticator
  48
  49 - could -sleep to tear down transient state (not used)
  50   - -sleep is called by the SoObjectRequestHandler
  51   - Note: also supports -_sleepWithContext:
  52
  53 - note that the EOAdaptor is created by the object, but the channel is created
  54   by the method (the component)
  55   - the object itself is not really active, the methods should be active
  56   - the distinction here is blur, in general I would avoid methods which would
  57     require an [[WOApplication application] context]
  58
  59 - we are not really clever with DSoUserManager and DSoDatabaseManager,
  60   those two classes are basically identical
  61
  62 - the "GET" method is explicitly mapped in product.plist for the application
  63   object because otherwise "GET" will be treated as a hostname (because we
  64   perform no check on the hostname!)
  65   - need to check whether we can make SOPE smarter on this front, but I guess
  66     that issue is inherent to all containers which map to arbitary, external
  67     collections
  68   - we could create an EOAdaptor and connect it to 'template1', but this would
  69     result in one unnecessary DB connection?
  70   - Note: this is not a problem for methods which are registered in
  71           products.plist - those are found in the SoClass. But the system
  72           checks for some keys during its traversal process (and expects
  73           getting a nil if the key does not exist).
  74
  75 - when redirecting to the DSoHost object, we need to ensure that we add a slash
  76   - otherwise the relative URLs will be broken!
  77   - in theory SOPE should make a redirect to the default method, not sure why
  78     this isn't happening
  79   - ZideStore always makes such a redirect?
  80   - maybe any folderish object when being at the end of a traversal stack
  81     should check that?
  82
  83 - acquisition
  84   - if you override -lookupName:inContext:acquire:, you should probably
  85     disable acquire in super calls! - otherwise all name processing code
  86     coming after the [super lookup..] is overridden by objects in the
  87     acquisition mechanism
  88   - note that acquisition is also done on the traversal path! if the lookup
  89     returns nil on an URL path being traversed, URL acquisition will occure
  90     (except on non-acquisition protocols like WebDAV)
  91
  92 - baseURL
  93   - calculation of base URL requires you to either override -baseURLInContext:
  94     or implement -container and -nameInContainer
  95
  96 - enabling WebDAV
  97   - implemented -isCollection in DSoObject
  98   - per default the baseURL is broken - you need to ensure that it returns
  99     a proper value, see above
 100     - if the baseURL doesn't match the requested WebDAV URL, we run into
 101       problems, maybe need to fix something in the SOPE WebDAV layer here