- formatting is inspired from, and use when possible, standard logging. "message", "levelname", and "name" are the only format managed, depending on backend more can be managed (standard backend formats are specified in official python logging doc)
- name filter use regular expressions. It's possible to log only plugins with SAT_LOG_LOGGER="^sat.plugins". To log only XEPs 96 & 65, we can use SAT_LOG_LOGGER='(xep_0095|xep_0065)'
- output management use a particular syntax:
- output handler are name with "//", so far there are "//default" (most of time stderr), "//memory" and "//file"
- options can be specified in parenthesis, e.g. "//memory(50)" mean a 50 lines memory buffer (50 is the current default, so that's equivalent to "//memory")
- several handlers can be specified: "//file(/tmp/sat.log)//default" will use the default logging + a the /tmp/sat.log file
- if there is only one handler, it use the file handler: "/tmp/sat.log" is the same as "//file(/tmp/sat.log)"
- not finished, need more work for twisted and basic backends
- variable change logs behaviour, so far only level and colors are implemented
- configuration use log_[name], for example you can put log_level=debug in sat.conf (section [DEFAULT]) to see all levels
- environment variables use SAT_LOG_[NAME]: e.g. SAT_LOG_LEVEL=debug
- colors can be true, false or force to force colors even if stdout is not a tty
- added a core.log module
- 3 backends can be used: basic, standard (python's logging module) or twisted
- colors can be used
- the module has been made to be used by frontends, it should work in exotic environments like pyjamas
- logging basic configuration is now made in sat.tac
- core.log configuration is inspired from python standard logging, and use it when possible
- getLogger should be used the same way as for standard logging
- profileConnected are now executed in a deferredList, instead of one after the other
- failure are collected, and a global message show which plugins failed and the failure message
- hashing algorithm of XEP-0115 has been including in core
- our own hash is still calculated by XEP-0115 and can be regenerated with XEP_0115.recalculateHash
- old discovery methods have been removed. Now the following methods are used:
- hasFeature: tell if a feature is available for an entity
- getDiscoInfos: self explaining
- getDiscoItems: self explaining
- findServiceEntities: return all available items of an entity which given (category, type)
- findFeaturesSet: search for a set of features in entity + entity's items
all these methods are asynchronous, and manage cache automatically
- XEP-0115 manage in a better way hashes, and now use a trigger for presence instead of monkey patch
- new FeatureNotFound exception, when we want to do something which is not available
- refactored client initialisation sequence, removed client.initialized Deferred
- added constant APP_URL
- test_plugin_xep_0033.py has been temporarly deactivated, the time to adapt it
- lot of cleaning
- registerTextCommands can be called by a plugin in its __init__ method, it looks for methods starting with "cmd_" and register them as new commands
- addWhoIsCb: add a callback to /whois command, the callback can complete whois informations
- plugins parrot, XEP-0045 and XEP-0092 now manage their own commands
- "recommendations" key can be used in PLUGIN_INFO
- if a plugin can't be found an ImportError is raised if it's a dependency, if it's a recommendation only a warning message is shown, and plugins importation continue
- new Updater class check database consistency (by calculating a hash on the .schema), and updates base if necessary
- database now has a version (1 for current, 0 will be for 0.3's database), for each change this version will be increased
- creation statements and update statements are in the form of dict of dict with tuples. There is a help text at the top of the module to explain how it works
- if we are on a development version, the updater try to update the database automaticaly (without deleting table or columns). The Updater.generateUpdateData method can be used to ease the creation of update data (i.e. the dictionary at the top, see the one for the key 1 for an example).
- if there is an inconsistency, an exception is raised, and a message indicate the SQL statements that should fix the situation.
- well... this is rather complicated, a KISS method would maybe have been better. The future will say if we need to simplify it :-/
- new DatabaseError exception
