[Gzz-commits] manuscripts/SemFen article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/05/02 07:34:36

Modified files:
        SemFen         : article.rst 

Log message:
        bit

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/SemFen/article.rst.diff?tr1=1.24&tr2=1.25&r1=text&r2=text

Patches:
Index: manuscripts/SemFen/article.rst
diff -u manuscripts/SemFen/article.rst:1.24 manuscripts/SemFen/article.rst:1.25
--- manuscripts/SemFen/article.rst:1.24 Fri May  2 07:19:41 2003
+++ manuscripts/SemFen/article.rst      Fri May  2 07:34:36 2003
@@ -3,7 +3,7 @@
 ==========================================================================
 
 
-.. :Stamp: $Id: article.rst,v 1.24 2003/05/02 11:19:41 tuukkah Exp $
+.. :Stamp: $Id: article.rst,v 1.25 2003/05/02 11:34:36 benja Exp $
 
 .. Authors: Benja Fallenstein, Tuukka Hastrup, Tuomas J. Lukka
 
@@ -272,6 +272,9 @@
 - with complicated and connected information structures,
   UIs should reflect the connections
 
+When a user clicks on a link in a conventional Web browser,
+
+
 - today's UIs bad:
 
     - change-whole-window mentality
@@ -323,6 +326,32 @@
 
 The Swamp RDF API
 -----------------
+
+In an architecture regenerating all views from an RDF graph
+after each keypress by a user, the performance requirements
+for the RDF API used are at a premium. We have surveyed 
+existing RDF APIs for Java, such as Jena [ref], but have found
+their architecture not matching the special needs of our system.
+
+In order to archieve acceptable reaction times, we need to
+cache parts of views that the user's key press did not change;
+for example, the vob representations of individual nodes
+that the user did not edit. However, we also need to
+prune the cache when the user *does* edit a node.
+
+To archieve this, we have developed the Swamp API for RDF,
+which allows us to attach observers to particular lookups
+done on the graph. When the observed part of the graph changes,
+the observer is notified and the graph can be regenerated.
+
+Additionally, we have taken care that all lookups in the
+Swamp API take O(1) time in the number of nodes in a graph,
+and that no Java objects need to be created during the lookups
+done in inner loops. (Object creation is costly in Java 
+because of the garbage collection overhead; while it is
+perfectly fine to create a few objects each time the user
+presses a key, generating a few thousand can lead to
+noticeable delays.)
 
 - Java API focused on performance