Changes between Version 3 and Version 4 of Grass7/RPCInterface

Timestamp:

Apr 23, 2014, 1:28:56 AM (10 years ago)

Author:

huhabla

Comment:

--

Grass7/RPCInterface

@@ -10 +10 @@
 
 The benefits of a RPC interface are:
- * the ability to implement fast and well function persistent client applications like GUI's
+ * The ability to implement fast and well function persistent client applications like GUI's
  * Support for different programming languages on client side (Python, C++, Java, JavaScript) that will have access to GRASS library functions
  * Implementation of GUI specific functionality, hence bundling of GRASS library functions on the server side
@@ -20 +20 @@
 I would strongly suggest to use apache thrift[1] to implement the RPC interface for GRASS core libraries. This framework support plenty of programming languages, adds minimal dependencies and provides platform independent RPC functionality (data serialization, IPC). 
 
+The RPC interface will not only do simple function wrapping, it will
+also implement a higher level interface:
 
+ * Map metadata read access as single client function will do on the server side: open map; read metadata; close map; send data
+
+ * fast raster and vector map read access as single client function will do on server side: open map; read requested map into memory based on bounding box and render resolution; close map; send data
+
+ * vector editing: keep a single vector map in update state open in a dedicated grass vector editing process. In case of a fatal error, this map may be lost or corrupted. It is important that this process will not be used for other purposes than single vector map editing.
+
+ * vector analysis functionality that need to keep vector maps open in read only state for fast topological access. Information's about the open vector maps (i. e. the position of the next line to be read) may be lost in case the server process terminates.
+
+ * Same for raster map analysis
+
+The client will detect if the server was terminated and will raise an exception. 
+
+The RPC interface should only support meaningful functions to be used in a GUI, that's its only purpose.
+It should not be used to implement processing algorithms or GRASS modules. But it will in addition provide capabilities to use several processes
+to read different chunks of the same map in the GUI, hence parallel read only map access. This can be nicely done using a
+pool of GRASS server processes.
 
 [1] https://thrift.apache.org/