From: Vincenzo aka Nick Name <vincenzo_mlRE.MOVE@yahoo.it> - 2004-08-14 09:13:36
There are two issues with the way one should create data on the
1. If I record attributes of a file on the db, the user is (not without
a reason) tempted to change these attributes directly on the db, e.g.
to fix a typo in the "author" tag of hundreds of mp3s.
2. If a plugin uses attributes of another plugin they must be called in
the right order
A possible solution, which pushes hard towards the decision of having a
library to create datastructures on the database instead of allowing
plugins to create tables (and this makes one think that having a
separate user at least for groups of plugins is a good idea), is to
create triggers on the database for attributes "owned" by plugins, both
on read and on write:
- Read triggers:
When anybody tries to read an attribute, the database should check
conditions, declared by plugins and choosen in a limited range (like
"when the first 100 bytes of the file have changed"), which might have
invalidated the attribute, and in this case run the appropriate
indexer. This solves the dependency issue but NOT if there are circular
dependencies which are a bad thing anyway. Several ways to avoid
circular dependencies come to mind but none is free from troubles.
- Write triggers:
When anybody tries to write an attribute (except the owner of the
attribute, which makes the choice "a db user for each plugin" an
interesting concept) the database should check if there is a plugin
which has declared itself able to write that attribute, or else return
we will have to implement a library, possibily easy to call by C and so
"SWIG"able, which allows to declare "external types". Types should have
- attributes with "DB primitive" types, that are translated to column
of a table with the same name of the type
- attributes with "external" types, which are translated using foreign
- declarations of writeable-ness for attributes, and what to do in the
case of a write.
Types should be inserted into suitable database schemas to avoid naming
conflicts, and what db schema to use might be chosen either by letting
the plugin declare it, or as beerfun said using a fixed set of rules
(like "what mimetypes do you match" but not limited to mimetypes) that
group plugins together in a more automatized way.
A last note is worth for "equalization" of attributes i.e. what if two
plugins use different names for the same thing, and the user notices
this? She should be enabled to "equalize" the names but I am unsure of
the implications of equalization even if semantics of name passing is
one of my favourite topics :) However we should see if this can be
worked on easily because that would be a great advantage.
Someone willing to criticize this architecture? This will be implemented
in september because I'll be on vacation in the next two or three