> The fields that are going to offer challenges are those used for
> sorting (score, creation date, title, etc) and filtering (expiry,
> type). When you fetch() an article you will allways fetch the
> original, and the ID of the symlink will be available so you
> can call up the data of the symlink. But for sorting and filtering
> to work the related fields will need to be clones of the original
> at all times.
>
> Argh. All this doesn't even take into account reply articles. Who
> would've thought something so conceptually simple would turn
> out to be so complex?
I wonder if symbolic links are the right conceptual model here.
Really what you have in the articles is two types of information:
'content,' with components that are closely bound and are
relatively isolated from anything external; and then apart from
content some kind of 'package', consisting of components that
are configured to arrange and express the article content in
the environment in which it's referenced.
This suggests that article_content might be disconnected from
topics altogether, and then joined with (at least one)
article_package, of which there may be many versions
registered under different topics, but all referencing the
same article_content.
Maybe looking at it this way gets us out of having to think
about the problems of which is the 'master' article, and where
should it be located.
Make any sense, or does this just muddy the waters?
Paul
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
