Index: ossp-pkg/srpc/BRES
RCS File: /v/ossp/cvs/ossp-pkg/srpc/BRES,v
rcsdiff -q -kk '-r1.1' '-r1.2' -u '/v/ossp/cvs/ossp-pkg/srpc/BRES,v' 2>/dev/null
--- BRES	2001/06/21 05:16:05	1.1
+++ BRES	2001/06/28 14:08:00	1.2
@@ -7,6 +7,18 @@
   - eXtendable Data Serialization Library: libxds
   - Simple Remote Procedure Call Library: libsrpc
 
+- libxds does intentionally NOT support the concept of arrays and
+  structures ("sequence" and "record" in ASN.1-speak), because not all
+  encoding systems support structured data. Hence, someone who'd want
+  to decode the serialized buffer cannot rely on this information
+  actually being included in the encoded data.
+
+  The only use of having these capabilities nonetheles would be that
+  the decode function could type-check the specification of what has
+  been received against the actual contents of the data. While this is
+  nice to have, we did not consider this to be reason enough to add
+  complexity to our interface and implementation.
+
 - The server actually performing the function call has to interpret
   the transferred data according to the functions prototype. This may
   be done in one of the following ways:
@@ -27,14 +39,14 @@
   because
   o constant function prototype on server-side
     (foreign function call problem!)
-  o only application knows how to convert 
+  o only application knows how to convert
     complex data structures (foo_t) into
     serialized octet-stream
   o greater flexibility in data transfer
   o rpc library complexity is reduced
     (on cost of application complexity)
 
-  instead remote procedure call 
+  instead remote procedure call
   only message passing
 
 - auditing/logging:
@@ -46,7 +58,7 @@
   sepatered from data serialization
 
 - error semantics:
-  transaction, ACID 
+  transaction, ACID
   o exactly-once (== 1) bank transaction
   o at-least-once (>= 1) muss passieren, mehrfach tut nicht weh (seiteneffekte) SunRPC
   o at-most-once (<= 1) logging of not important data, video conferneces
@@ -61,7 +73,7 @@
 
 - asynchronous vs. synchronous
   Ideee: intern immer asynchrouns
-  aber in API wrapper function 
+  aber in API wrapper function
   rpc_call == rpc_send+rpc_wait+rpc_result
   und auch rpc_abort
   trotzdem wird beide male ein timeout vorgesehen
@@ -135,7 +147,7 @@
 
 - Firewalls? Sollen die Filtern koennen
   Encryption nur von Data, nicht von Meta-Data
-- Proxies? 
+- Proxies?
 
 - Sowohl AMP als auch XDR muessen backends von
   Application implementieren lassen!
@@ -153,7 +165,7 @@
   - Fail Over
 
 - IPv6 in AMP unterstuetzen
-- Multicasting in AMP unterstuetzen (trivial I/O seitig, 
+- Multicasting in AMP unterstuetzen (trivial I/O seitig,
   aber muss bei error semantics beruecksichtig werden)
 
 =========================================================================================