[RDF] The next step

[Jonas Liljegren]

I thought I would have 0.04 out several weeks ago.  But it got more
complicated than I expected.


Then I started to design Wraf I was trying to find a balance there
cached information can be used by many sessions, but not at the
expence of the flexibility for each session.

A session is a connection to the RDF::Service server via the cgi
client program.  The service combinds data from several sources and
gives access to them as one whole.

A particular request for information will give diffrent answers
depending on what interfaces (data backends) the session as cennected
to.  Each combination of connected interfaces is given a unique key
called IDS. Every IDS has it's own cache.  The idea is that it in the
common case will be many sessions using the same IDS cache.

Every part of the sstem will themself be represented by RDF
resources.  A new session object (identified with the URI of the
resource) starts by connecting to the Base interface.

The DBI interface is separate from the core. The server program first
creates the session object and will then connect to the DBI
interface.  This means that the session metadata (mainly the creation
time of the 'model') will be created in a IDS without the ability to
storage the data.

This was solved by introducing general code to copy unsaved data
belonging to the model (ie session) from one IDS cache to another and
to recursively also copy all unsaved data referenced.  The storage
system was redone to keep tags on what has been commited (stored) and
what has not.

A future data addition followed by a storage will store all unsaved
referenced data.  This will save the session metadata the instance it
is referenced by anything else.  This also makes it possible to defere
the database work until after the response has been sent to the
client.


My original plan to keep the diffrent IDS caches syncronized was to
make changes in one IDS expire the related items in the other IDS and
let the updated value come from the appropriate interface.


All this has forced me to much more testing of the validity of the
internal datastrucutres.  On dubug level 4 and hither, a validation
will be done before and after every function call.  As a result of
this, everything is more solid now.  Especially the base and session
resources.



There are still tons of things to include and optimize.

* The core often want's to list the types of a resource, ordered by
  their place in the class heiarcy.  This has been done by giving
  every class a LS:level property.  That should go in the core to
  avoid a full blown "search request" for every pair comparsion in the
  sorting of the classes.  

* A general solution will have to be developed for sorted lists in
  general.  Lists are represented by containers.  The iteration
  through those containers will be done in a specified order.

* I haven't yet created the code for using namespaces.  The context
  will have a list of namespaces and those will be used while viewing
  the resources.  This will for example be used by the desig()
  function.

* A request for returning a list of resources will normaly do so by
  returning a Selection container resource.  This gives a lot of
  internal overhead.  Some shortcuts is and will be created.  But more
  important is that a normal selection doesn't have to be stored in
  the cache.  This can easily be fixed by creating a new constructor
  for those types of temporary resources.

* The server should be avare of its memory consumption.  Old or little
  used cached resoruces should be expired.

* The DBI interface stores the URI of resources it doesn't have to
  store.  A cleanup could be done of nonreferenced URIs.  But it would
  be nicer if the interface wouldn't create those records in the first
  place.

* Most of the described API hasn't been created.  The API will give a
  session object methods with the name of the property for accessing
  that property.  But those names are a short name for the full URI.
  And those shortcuts must be specified for each session or context.
  That means another level of indirection.  I would like to avoid
  that...

More things is on the TODO list (in the doc directory).


The next step is to start implementing the presentation system.
Primarly for presentation in HTML form.  I will take another look at
XSLT but will probably not use it.  I will either create som custom
(treelike) system or base it on the Template Toolkit 2.01:
        http://search.cpan.org/search?mode=dist&query=Template-Toolkit

The new VIEW feature may be exactly the right thing:
        http://www.uxn.nu/wraf/tt2/html/Views.html


Maby I will take the time to write some documentation.  Especially a
document that defines all the terms used.

-- 
/ Jonas Liljegren

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