Comment 37 for bug 602211

All of these clever remapping schemes scare me a bit to be honest.
They all seem to imply a non-negligible impact on our query time, and
a considerable amount of logic.

A simpler and more performant scheme, which requires an API break (!),
is to simply add an extra field on our Subject structure
"current_uri". In the DB we represent this as an extra column on the
'event' table which holds the URI id of the current location of the
subject.

Doing it like this would require that the file monitor lives inside
Zeitgeist - and not as an extension, but as a core component, since it
requires a special db structure. The file monitor would then directly
modify the 'current_uri' column of the 'event' table on file events.
This breaks our "events are immutable" invariant - which i'm otherwise
very fond of... So there are many drawbacks to this approach.

Despite all the drawbacks something inside me tells me that something
like this is the right solution.

I very much dislike adding advanced stuff like a file monitor as a
core component, but we could make up for this, by having it be like a
stub, that didn't do anything by default, but would have to be
instrumented by an extension or something... So it requires air fair
deal of thought architecture wise...