README

Structure of afspy

afspy are (as the name suggests) python bindings to AFS, here
in the implementation of openAFS.

Layout :
========

afs/ : The actual module
afs/dao/ : low-level interface
afs/service/ : high-level interface
afs/exceptions/ : custom exceptions
afs/util/ : helper functions

tests/ : unit-tests, requires some configuration to run in your cell
examples/ :  some example scripts

Usage
=====

Interactively:
PYTHONSTARTUP=<PATH/TO/afspy>/afs/util/pythonstartup python

in scripts:

see examples


Configuration
=============

Config options are read as :
1. read system wide configuration file:
   Path is hard-coded in module
2. read user's personal $HOME/.config/afspy
3. read config file given on command line
4. use options given on command line

Later definitions overwrite earlier.
This configuration is stored in a AfsConfig-object.
and passed to any service called by default.

Contents of the AfsConfig :
=====================

- Credential to use :
    """
    - use present
    - use keytab from file ...
    - pagsh; kinit  -k -t  $KRB5CCNAME; aklog ; call child..
    """
- default AFS Cellname
- default Keberos REALM
- DAO-implementation to use
- DB-implementation to use.
- Logging. There are two types of Loglevels,
  - the global one for all modules : 
     e.g.  globalLogLevel="[debug|info|warn|critical]"
  - a class local one to override the global one for certain classes.
    CSV list of Classname=Loglevel pairs:
    e.g. classLogLevels="CellService=warn,UbikPeerDAO=warn,FileServerDAO=debug"
    beside the normal classes, also "util" and "sqlalchemy" are available.


Policies :
========

* DAO returns dictionary of list of dicts
* DAO always raises an execption on error
* DAO are agnostic of the model.
* Partitions are used canonicalized only
* Id are integer. DAO has to convert it.  Same for quota,  number of files access
* Timestamps are datetime.
* DAOs are distinguished on the RPC-Level.
* Services never call another service,  but multiple DAOs


DB-Cacheing
===========

If the option DB_CACHE is set to True.
A connection to the configured DB is set up 
and stored in the AfsConfig-Object.
Every service creates its own session, so that any created Object is attached
to the DB-Cache as long as the service is alive.

LiveCommand Execution
====================
Live commands are executed in a separate process.


Names:
=======
BNode instead of Process.