[Gzz-commits] fenfire/docs/pegboard/swamp_rdf_api--tjl peg.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/fenfire
Module name:    fenfire
Changes by:     Tuomas J. Lukka <address@hidden>        03/04/06 11:18:05

Modified files:
        docs/pegboard/swamp_rdf_api--tjl: peg.rst 

Log message:
        Further design

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/fenfire/fenfire/docs/pegboard/swamp_rdf_api--tjl/peg.rst.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: fenfire/docs/pegboard/swamp_rdf_api--tjl/peg.rst
diff -u fenfire/docs/pegboard/swamp_rdf_api--tjl/peg.rst:1.1 
fenfire/docs/pegboard/swamp_rdf_api--tjl/peg.rst:1.2
--- fenfire/docs/pegboard/swamp_rdf_api--tjl/peg.rst:1.1        Sun Apr  6 
09:03:04 2003
+++ fenfire/docs/pegboard/swamp_rdf_api--tjl/peg.rst    Sun Apr  6 11:18:05 2003
@@ -3,8 +3,8 @@
 =============================================================
 
 :Author:   Tuomas J. Lukka
-:Last-Modified: $Date: 2003/04/06 13:03:04 $
-:Revision: $Revision: 1.1 $
+:Last-Modified: $Date: 2003/04/06 15:18:05 $
+:Revision: $Revision: 1.2 $
 :Status:   Incomplete
 
 This document outlines the main issues in the Jena api
@@ -16,6 +16,43 @@
 
 - Are there any APIs out there that already support our needs?
 
+- Do we want implicit or explicit observers?
+  Gzz used explicit observing, due 
+  to having an object per cell. However, the tradeoffs are different
+  here.
+
+  The benefits of implicit observing are ease and purity of the functional
+  approach: in the explicit approach, forgetting a single obs somewhere will 
+  make the code buggy in a potentially dangerous way. However, the implicit
+  observing requires wrapper objects for all parts of the API.
+
+    RESOLVED: Implicit observing, since we *can* wrap all parts
+    of the API without too much cost. If the API is non-object-oriented,
+    in the sense that the individual nodes and statements are not tied 
+    to any model/space, we only need to wrap O(1) objects.
+
+    Additionally, we can cheaply make "derived" models, 
+    e.g. when implementing the model_versions--tjl stuff.
+
+- How should resources and properties be represented?
+
+    RESOLVED: As hashable Objects with '==' comparison semantics.
+    The resources are mapped to and from Strings through a 
+    global resource name mapper / compressor.
+
+    We need to save memory and e.g. the URN-5 names
+    are too many and too long. The compressor would return either
+    strings with a prefix markup (i.e. a funny character and an index
+    to a prefix table) or an object with an integer (for the number part)
+    and an interned string for the shared part.
+
+    For properties and other such resources, interned strings should be 
sufficient.
+
+- How should literals be represented?
+
+    RESOLVED: As immutable Literal objects, with several types of accessors.
+
+
 Problems with jena
 ==================
 
@@ -38,23 +75,6 @@
 Design
 ======
 
-The first, most important design decision is between implicit
-and explicit observing. Gzz used explicit observing, due 
-to having an object per cell. However, the tradeoffs are different
-here.
-
-The benefits of implicit observing are ease and purity of the functional
-approach: in the explicit approach, forgetting a single obs somewhere will 
-make the code buggy in a potentially dangerous way. However, the implicit
-observing requires wrapper objects for all parts of the API.
-
-I'm in favour of implicit observing, since we *can* wrap all parts
-of the API without too much cost: if we make the API non-object-oriented,
-in the sense that the individual nodes and statements are not tied 
-to any model/space, we only need to wrap O(1) objects.
-
-Additionally, we can cheaply make "derived" models, 
-e.g. when implementing the model_versions--tjl stuff.