Fixing tests
============

* unit tests pass when used with all.py,
  but *not* with python -m unittest discover -s utest -p "[b-z]*.py"
* might this depend on the order?
  (indeed, all.py does execute backend_slite.py first, which would explain
   why it passes)
* all interactions seem to come from core_element;
  here are the interactions that I spotted:
  - TestEvents makes util_session.TestSession.testMultipleThreadUndefined fail
  - TestUnreachable makes a lot of tests in backend_sqlite fail
  - combinations of two of {TestElements, TestTagAsGroup and TestReferences} make those tests fail as well

Questions
=========

- filter elements against media

- backend method: search_string + options

- How to properly implement TALES query ? It was a global method, but
   it could be a core.element method, although it prevents its use as
   a filter on a standard list.

- How to express the same thing as matchFilter (essentially, which
   element does the view apply on) -> toplevel metadata

Needed improvements
===================

Important improvements
======================

- add the synchronized decorator to all methods that need it

- make package loadind/saving robust to Windows filenames.

- finish the implementation of utest/core_package test_modify_X methods

- export advene1 -> advene2 (in advene1)

- prevent annotations/relations to be untyped

- implement ID generator

- check in can_reference that "embeded" elements are not references outside
  their embeding elements

- align backend granularity on notification granularity (i.e. tell the backend
  to change a specific attribute in an element)

- add parameters X_with_prefix and X_exclude_prefix in backend_methods
  (id_with_prefix, id_exclude_prefix, media_with_prefix, etc...)

- augment backend method iter_tags_with_element with attributes tag_with_prefix
  and tag_exclude_prefix ; may be symetric iter_elements_with_tags

- implement read or write locking, "force", and "readonly" in _SqliteBackend

- implement content handlers for queries and models, in the same way it has
  been done for views

- ensure that the import "cam" is never renamed

- advene_zip: make unit test with accented filenames stored in the
   package, to ensure that there is no problem with multiplaform
   encodings

Minor improvements, to do one day
=================================

Backend related
---------------

- add indexes in the SQL schema (Annotations.f_begin at least)
  and test its efficiency

- implement count_lists_with_items and update all_group and own_group

- it seems that JOIN's with view UriBases are a little less efficient
  than JOIN's with tables Packages and Imports and an explicit condition
  so removing UriBases (at least in some queries) would be an interesting
  optimization (see count_relations as an example)

Misc
----

- remove unused code in advene/utils once we are sure we won't use it

- remove "unstable and experimental" in parser and serializer docstrings (once
  it is stabilized and tested, that is ;)

- use notification of events, once implemented, to clean the package root
  created by parsers/advene_zip.py and content.py

- in advene/utils/files.py, improve if necessary the URL proxy

- try to improve XML parser, either by using DOM (instead of event stream)
  or a native parser (expat?)

- make incoming_relations and _tales_incoming_relations dependant on a
  common _get_incoming_relations method, so that they do not diverge
  (see implementation of my_schemas in advene.model.cam.tag)

Open questions and remarks
==========================

- Olivier would like collection-like objects (own-group, all-group, relations,
  lists...) to implement __getitem__. I do not see the real added value since,
  if you know the id, you would rather call package[id] than package.own[id]
  or package.own.annotations[id]. To discuss...

- from Jul 13 2007 to Aug 03 2007, module advene.model.core.dirty was used to
  delay accesses to the backend, in order to make modifications more
  responsive. It appeared that this was no a good idea: the backend is not only
  used for storage, but also for *indexing*. As a consequence, many methods
  rely on the backend for efficient retrieval of sequences of objects, hence
  requiring the cleaning of involved objects, and hindering access for the
  sake of modifications. So that functionality has been discarded. Should it
  become necessary in the future (the current sqlite backend seems to be
  responsive enough, anyway), it should probably be implemented at the backend
  level itself.

- may be it is a bad idea that parsers use the Package API instead of the
  backend API (it provides more checks, but also more automated behaviours
  that need to be circumvented for the parser, like the creation of
  element-constraint view in Annotation/Relation types). So this should be
  reconsidered.
