[RDF] Current issues

[Jonas Liljegren]

Ok. Just want to write a little about the things I trying to do right
now.


The client-server separation realy speeds things up. But the real job
is to keeping the cached data correct while allowing additions and
deletions.



The cyclic dependencies is still haunting me. Half of the time, the
first object will not even initialize because the initialization
process require initializations of other objects, that need other
objects.

I pull the plug on level 20.  In the deepest levels, it still tries to
initialize things with the help of other objects not yet initialized.

My thoughts here is to make special handlings of the basic classes
needed by the initialization process itself.  This could maby be done
by going through a series of bootup stages and let the stages decide
what to do.

But that can wait. The new wave of cyclic dependencies was a result of
new functions introduced.  Mainly a function to sort the types of a
resource according to its place in the object heiarchy.  (The
specialized functions should be called before the most general
versions.)  In the battle to get the classes to initialize, I inserted
the whole Schema class in the base class and put the actual schema
data in the constant moudule.



I have spent a lot of time thinking about the dynamic properties.
What should we do if a resource has two properties; prop A depends on
the content of prop B and prop B depends on the content of prop A?

I was thinking about first initialize B, then A, and then B agian.
But that will not do it.  I'm not happy with this.  I guess I will
just make the property initialization fail in the face of this cyclic
dependency.

The current reason is that I am declaring dynamic subClassOf
properties, that depends on the existing subClassOf properties.  I
have thinked about a couple of diffrent ways to do this.  

One version is to in the interface registration (the place there the
interface tells the server which mathods it has to offer, depending on
the namespace and type of resource) add info about what other
properties it depends on.  The creation of those properties would then
trigger the creation of the dynamic property.

Another way is to let the creation function call the properties it
depends on.  It would registrer itself in the context.  The dispatcher
could check the context before it dispatched a call, to avoid loops.
This would result in that the dynamic subClassOf would call the static
version, if it was not yet called.  I think this is what I will do.



The other thing to do is to remember the dependency of the properties
in such a way that the removal of a statement will remove/update all the
dependent statements.

I started twith DEPEND data, but have changed my mind now.  TYPE and
REV_TYPE can be used both as the source for answering queries and to
remember depends.  I thinking that if the selection objects is used to
store other types of query responses, they will use this system too.
This got me to (internally) rename PROP and REV_PROP to REV_SUBJ and
REV_OBJ respectively, and add REV_PRED just for completeness.

And talking about completeness. Each of these base data string will be
able to handle partial answers and will have an extra flag to say that
all data from the connected interfaces has been retreived.


I am tempted to store all sort of metametadata (used in the program)
as regular props and even to convert the TYPE data to real type PROPS,
but I'm afraid that that will make the cyclic dependency problem even
worse.  And You have to stop at some point. The internal description
of itself could generate an infinity of statements.  Some of them have
to be implicit.



-- 
/ Jonas Liljegren

The Wraf project http://www.uxn.nu/wraf/
Sponsored by http://www.rit.se/