/[gzz]/manuscripts/SemFen/article.rst
ViewVC logotype

Diff of /manuscripts/SemFen/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.24 by tuukkah, Fri May 2 11:19:41 2003 UTC revision 1.25 by benja, Fri May 2 11:34:36 2003 UTC
# Line 272  UIs for Data linking / blending Line 272  UIs for Data linking / blending
272  - with complicated and connected information structures,  - with complicated and connected information structures,
273    UIs should reflect the connections    UIs should reflect the connections
274    
275    When a user clicks on a link in a conventional Web browser,
276    
277    
278  - today's UIs bad:  - today's UIs bad:
279    
280      - change-whole-window mentality      - change-whole-window mentality
# Line 324  VobScene: an extended Scene Graph Line 327  VobScene: an extended Scene Graph
327  The Swamp RDF API  The Swamp RDF API
328  -----------------  -----------------
329    
330    In an architecture regenerating all views from an RDF graph
331    after each keypress by a user, the performance requirements
332    for the RDF API used are at a premium. We have surveyed
333    existing RDF APIs for Java, such as Jena [ref], but have found
334    their architecture not matching the special needs of our system.
335    
336    In order to archieve acceptable reaction times, we need to
337    cache parts of views that the user's key press did not change;
338    for example, the vob representations of individual nodes
339    that the user did not edit. However, we also need to
340    prune the cache when the user *does* edit a node.
341    
342    To archieve this, we have developed the Swamp API for RDF,
343    which allows us to attach observers to particular lookups
344    done on the graph. When the observed part of the graph changes,
345    the observer is notified and the graph can be regenerated.
346    
347    Additionally, we have taken care that all lookups in the
348    Swamp API take O(1) time in the number of nodes in a graph,
349    and that no Java objects need to be created during the lookups
350    done in inner loops. (Object creation is costly in Java
351    because of the garbage collection overhead; while it is
352    perfectly fine to create a few objects each time the user
353    presses a key, generating a few thousand can lead to
354    noticeable delays.)
355    
356  - Java API focused on performance  - Java API focused on performance
357    
358  - observers  - observers

Legend:
Removed from v.1.24  
changed lines
  Added in v.1.25

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26