Re: Next steps for Caja-CapTP

On Oct 14, 2009, at 0:29, [email protected] wrote:
> On Mon, Oct 12, 2009 at 4:24 AM, Kevin Reid <[email protected]> wrote:
>> Point: The *tests* currently require E support; the library  
>> itselfThese tests are all of infrastructure though; none of them are
>> actually at the level a *user* of the system would be working,  
>> because
>> that level has not been implemented yet.
>>
>> A user of a full CapTP system works purely in terms of SturdyRefs,  
>> far
>> refs, and the Introducer/MakeSturdyRef authorities; they don't see  
>> any
>> of the infrastructure currently existant.
>
> Sure ... but the user would presumably also be plugging in a
> transport, with the appropriate interface, right?

I forgot about that aspect. Yes. But that interface also does not yet  
exist, and in fact has yet to be designed.

What's your *first* use case? The original plan was to use symmetric  
HTTP as the first transport (that is: both ends of the connection may  
send HTTP
(POST) requestst to each other). Is there something else to do first?

>  http://codereview.appspot.com/8706/show
>
> Mike Samuel has created a JS doc tool that (as I understand it) allows
> Updoc style tests in the documentation. I have not used it, but please
> ask Mike about it and see if it suits your needs. Specifically, I
> think you need it to run *Cajita* code as Updoc, not simply regular
> JavaScript code. I don't know if, or how, Mike's JSDoc supports that.
> Please do ask him.

I see.

Running Cajita code would be desirable, but writing the tests in plain  
JS would likely be no more code noise than the current writing them in  
E.

A brief glance suggests that this tool supports only synchronously- 
executing tests (no waiting across turns), which is absolutely  
necessary for the CapTP tests (and best done in the context of a  
promise system).

It is also desirable that the test framework support capturing an  
output stream that is considered test results to be matched (which I  
assume this doesn't do because <http://codereview.appspot.com/8706/patch/60602/60608 
 > does not have syntax for this, and also seems to be *parsing* the  
result-expressions, which is backwards) and that the tests don't

In summary, it superficially appears that it would be in the end  
cleaner and simpler to adapt the existing EoJS Updoc driver to be a  
pure-JS system rather than altering this 'jsdoc' to have the necessary  
functionality -- unless it is part of the plan anyway.

But I'm not sure that this opinion isn't just NIH.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>