CapTP

From Erights

(Difference between revisions)
Jump to: navigation, search
(add experimental specification of Data-E exits)
(+cat Pluribus)
 
Line 1: Line 1:
 +
See [http://www.erights.org/elib/distrib/captp/] for description and protocol documentation. The material should be moved here and rewritten into a specification.
 +
 +
Links to specification details should go right here.
 +
 +
== Specification exits ==
 +
 +
The CapTP specification, per se, does not specify these choices:
 +
 +
# The [[Miranda protocol]] all objects exposed over CapTP are expected to respond to. CapTP requires at least [[Miranda whenMoreResolved|__whenMoreResolved]].
 +
# The format in which CapTP messages are serialized for transmission over a byte stream.
 +
## The format in which objects embedded in CapTP messages are serialized in that stream.
 +
### The set of [[graph exit]]s; that is, those objects/[[maker]]s which both ends know about and can refer to in their serialized objects. The [[ad-hoc serialization comity]] proposal would mitigate this.
 +
 +
In an [[E]] system, these holes are specified to be filled with, respectively:
 +
 +
# [[Miranda protocol]]
 +
# {{XXX|Write this specification. See CapTP impl in E-on-CL}}
 +
## Data-E, with CapTP-specific details as [[#Data-E configuration|below]].
 +
== Data-E configuration ==
== Data-E configuration ==
-
CapTP as fully implemented in [[E-on-Java]] uses Java serialization. The work-in-progress implementation of CapTP in E uses Data-E to serialize CapTP message arguments:
+
CapTP as fully implemented in [[E-on-Java]] uses Java serialization. The work-in-progress implementation of CapTP in E uses [[Data-E]] to serialize CapTP message arguments:
-
(This has all been made up by [[Kevin Reid]]; please critique.)
+
(This has all been made up by [[User:Kevin Reid]]; please critique.)
The [[graph exit|graph exits]] which are CapTP-specific are:
The [[graph exit|graph exits]] which are CapTP-specific are:
-
; <code>"CapTP_1_descs"</code> : The uncall recipient for all [http://www.erights.org/elib/distrib/captp/index.html#descriptors descriptors]. For example, an [[ImportDesc]] is represented in Data-E as <code>CapTP_1_descs.import(importPos)</code>.
+
; <code>"CapTP_1_descs"</code> : The uncall recipient for all [http://www.erights.org/elib/distrib/captp/#descriptors descriptors]. For example, an [[ImportDesc]] is represented in Data-E as <code>CapTP_1_descs.import(importPos)</code>.
; <code>"CapTP_1_locatorUnum"</code> : The local presence of the [[LocatorUnum]].
; <code>"CapTP_1_locatorUnum"</code> : The local presence of the [[LocatorUnum]].
-
XXX Specify exactly what other graph exits should be available. for now it's the subgraph kit's default scope plus [[Ref]] and [[import__uriGetter]].
+
{{XXX|Specify exactly what other graph exits should be available. for now it's the subgraph kit's default scope plus [[Ref]] and [[import__uriGetter]]}}.
[[Category:To be specified]]
[[Category:To be specified]]
 +
[[Category:E specification]]
 +
[[Category:Pluribus]]

Latest revision as of 16:04, 10 June 2009

See [1] for description and protocol documentation. The material should be moved here and rewritten into a specification.

Links to specification details should go right here.

Specification exits

The CapTP specification, per se, does not specify these choices:

  1. The Miranda protocol all objects exposed over CapTP are expected to respond to. CapTP requires at least __whenMoreResolved.
  2. The format in which CapTP messages are serialized for transmission over a byte stream.
    1. The format in which objects embedded in CapTP messages are serialized in that stream.
      1. The set of graph exits; that is, those objects/makers which both ends know about and can refer to in their serialized objects. The ad-hoc serialization comity proposal would mitigate this.

In an E system, these holes are specified to be filled with, respectively:

  1. Miranda protocol
  2. XXX Write this specification. See CapTP impl in E-on-CL
    1. Data-E, with CapTP-specific details as below.

Data-E configuration

CapTP as fully implemented in E-on-Java uses Java serialization. The work-in-progress implementation of CapTP in E uses Data-E to serialize CapTP message arguments:

(This has all been made up by User:Kevin Reid; please critique.)

The graph exits which are CapTP-specific are:

"CapTP_1_descs" 
The uncall recipient for all descriptors. For example, an ImportDesc is represented in Data-E as CapTP_1_descs.import(importPos).
"CapTP_1_locatorUnum" 
The local presence of the LocatorUnum.

XXX Specify exactly what other graph exits should be available. for now it's the subgraph kit's default scope plus Ref and import__uriGetter.

Personal tools
more tools