Wraf: Jumptables

Every Interface has a hash tree that says, for each namespace and type, what methods it support.

Each node has a customized jumptable selectd from a jumpjumptable of jumptables. The jumptable connects each method name with a list of subroutine reference collected from the connected interfaces. The key used in the selection of a jumptable consists of three parts:

  1. A orderd list of connected interfaces; the IDS
  2. A orderd list of domain prefixes
  3. A orderd list of types

A jumptable that doesn't exist gets created on demand. Nodes not used for method calls never needs a jumptable.

Circular dependencies

The jumptable depends on the list of types. But in order to determine the list of types for a specific Resource, you have to call init_types(), which will be called from the jumptable. This situation is resolved by temporary setting the Resource type list to RDFS:Resouce. A temporary jumptable gets created and init_types gets called. The jumptable will at least know which interfaces that handles the specific resource, based on its URI. The init_types() must be located in the RDFS:Resouce section. After the types has been initiated, the original call will be dispatched.

The internal method declare_add_types() (that is called by the interfaces implementations of init_types()) will need to call init_props() (that initialize all the nodes properties) for each class in order to find subClassOf properties. That will lead to infinite recursions for some top classes. RDFS:Resource never gets a chanse to define it's types since init_types() calls init_props() for itself. this has been resolved by skipping the subClassOf calls for RDFS:Literal, RDFS:Resource and RDF:Statement; ie all the types of nodes that are created by the init_props() process. (I not yet fully understands what happens here.)

All context/client-dependent functions should use the session object methods or send it in as a parameter. This construction is a compromise to shorten the method calls in most cases, so that we doesn't have to tag along the context varaible evrywhere and so that we still can reuse the cached resource objects between more than one session.