# CapTP

### From Erights

(Difference between revisions)

Jump to: navigation, search

**Revision as of 11:00, 18 September 2008 (view source)**Kevin Reid (Talk | contribs)m (Reverted edits by Zarutian (Talk); changed back to last version by Kevin Reid) | **Latest revision as of 16:04, 10 June 2009 (view source)**Kevin Reid (Talk) (+cat Pluribus)  
---|---  
Line 1: | Line 1:  
-| See [http://www.erights.org/elib/distrib/captp/] for description and protocol documentation.| +| 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 12: | 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

##  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.