[sc34wg3] Possible TMRM issue

[Robert Barta]

On Mon, Mar 20, 2006 at 01:51:47PM +0100, Lars Marius Garshol wrote:
> The problem is that it's far from obvious how this can be done  
> without having to traverse the entire model every time a change is  
> made, or, alternatively, every time you want to compare two proxies.  
> What we need is some kind of reassurance that it is *possible* to  
> implement this efficiently. If it's not possible to do this  
> efficiently I don't think the current model is acceptable at all, and  
> if only Robert knows how to do it I'm afraid we'll only ever see one  
> implementation of this (Robert's).

Well, it would certainly help me with my hidden agenda to rule this
planet (actually I forgot why I would actually want that).

But, to bring this highly academic discussion more back-to-earth, here
is an excerpt out of

   http://cvs.sourceforge.net/viewcvs.py/perlxtm/base/lib/TM.pm?rev=1.21&view=markup

struct 'Assertion' => [
    lid         => '$',
    scope       => '$',
    type        => '$',
    kind        => '$', # argh
    roles       => '$',
    players     => '$',
    canon       => '$',
];

This is the low-level structure I currently use for a proxy (named
'assertion' for historical reasons). 'lid' is the label for this
proxy, computed from the 'roles' (=keys) and the 'players' (=values). 
'Roles' is a list of labels, 'players' is a list of things, either 
labels or literals (integer and other primitive stuff).

EVERY information (topic names, occurrences, blah, associations) are
mapped into such structure. I would DEFINITELY claim that this is
implementable, traversable, queryable, serializable, indexable and
amenable to various persistent storage techniques (not only relational
databases).

Otherwise, I would really wonder how my TM-server would have been able
to ship > 2 GB on TM content last month.

\rho