CapTP
From Erights
(Difference between revisions)
Kevin Reid (Talk | contribs) (improve links) |
(+cat Pluribus) |
||
(One intermediate revision not shown) | |||
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 == | ||
Line 10: | Line 29: | ||
; <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:
- The Miranda protocol all objects exposed over CapTP are expected to respond to. CapTP requires at least __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 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.
- The format in which objects embedded in CapTP messages are serialized in that stream.
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 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.