Next steps for Caja-CapTP

[ihab.awad]

Hi everyone,

Mike Stay and I are planning to use Caja-CapTP:

  http://code.google.com/p/caja-captp/

as the secure object-oriented RPC substrate for our Shahar project:

  http://code.google.com/p/google-caja-shahar/

To that end, we have certain things we are thinking of doing:

a. Remove the dependency on E-on-Java and E-on-JS, resulting in a pure
Cajita project. (The Caja-CapTP tests are currently written in Updoc
format. We can refactor directly to jsUnit-style tests, or consider
Mike Samuel's JSDoc tool that gives Updoc-like functionality.)

b. Refactor the interdependencies between Caja-CapTP source files to
use the new, EMaker-style Cajita module system that Ziqing Mao
implemented over the summer. (Caja-CapTP predates this module system.
The module system has unfortunately not been well-documented yet.)

Thoughts?

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

On Oct 11, 2009, at 21:40, ihab.awad@... wrote:

> a. Remove the dependency on E-on-Java and E-on-JS, resulting in a pure
> Cajita project. (The Caja-CapTP tests are currently written in Updoc
> format. We can refactor directly to jsUnit-style tests, or consider
> Mike Samuel's JSDoc tool that gives Updoc-like functionality.)


It is a design goal of Caja-CapTP to eventually interoperate with  
other CapTP implementations, of course including the 'normal' E-based  
implementations.

I wish that the test suite in Caja-CapTP continue to parallel as  
closely as possible the test suite for CapTP-in-E (which currently  
exists as a component of E-on-CL), from which it was derived, so that  
improvements to tests (which are greatly needed on both sides) may be  
shared.

I will not support any changes which will remove opportunities to  
avoid duplicated effort in the future. We are in general desperately  
short of available time from interested programmers.


1. Why do you wish to remove these dependencies?

    1a. If because E-on-Java is awkward to install, would the existence
        of a simple installer for Unix-style operating systems, and
        perhaps other changes to make things more pleasant, resolve  
this?

2. Would removing E-on-JavaScript's dependency on E-on-Java, such that
    it was a pure-JS or possibly even pure-Cajita (maybe with some Java)
    system, suffice? (The necessary work here would be providing a  
parser
    for E written in JavaScript, perhaps by way of OMeta.)

3. Would revising the test suite such that, while still using the Updoc
    syntax for tests, the test code itself is Cajita, suffice?

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




_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[ihab.awad]

On Sun, Oct 11, 2009 at 7:50 PM, Kevin Reid <kpreid@...> wrote:
> On Oct 11, 2009, at 21:40, ihab.awad@... wrote:
>
>> a. Remove the dependency on E-on-Java and E-on-JS, resulting in a pure
>> Cajita project. ...
>
> It is a design goal of Caja-CapTP to eventually interoperate with
> other CapTP implementations, of course including the 'normal' E-based
> implementations.

Cool.

> I wish that the test suite in Caja-CapTP continue to parallel as
> closely as possible the test suite for CapTP-in-E (which currently
> exists as a component of E-on-CL), from which it was derived, so that
> improvements to tests (which are greatly needed on both sides) may be
> shared.

+1, with some questions below.

> I will not support any changes which will remove opportunities to
> avoid duplicated effort in the future. We are in general desperately
> short of available time from interested programmers.

That's a good point.

> 1. Why do you wish to remove these dependencies?

The main reason behind all these is to make Caja-CapTP easy to
integrate into Cajita projects. This was intended as a contribution to
further developing Caja-CapTP rather than a change of direction.

First of all, I'm really glad that you undertook this GSOC project and
I for one believe it will enable a huge amount of coolness. Thank you.

Speaking for myself, I am not ready to hack the core implementation or
the semantics of the tests. That said, my first step when trying to
learn a library is to look at the tests and use them as a set of
"worked examples" for how to use the library. In this case, the
"worked examples" were not in the language and runtime environment
that I was going to use for my finished product. So I took it upon
myself to rewrite the tests in terms of that environment, and so
hopefully to learn the library some more in the process.

I understand the need to have non-duplication of the tests. Perhaps
what we need may be comprehensive tests in E, and some "spot tests" /
"worked examples" in Cajita. I honestly don't know what the right
answer is at this point.

>    1a. If because E-on-Java is awkward to install, would the existence
>        of a simple installer for Unix-style operating systems, and
>        perhaps other changes to make things more pleasant, resolve
>        this?

Perhaps.

> 2. Would removing E-on-JavaScript's dependency on E-on-Java, such that
>    it was a pure-JS or possibly even pure-Cajita (maybe with some Java)
>    system, suffice? (The necessary work here would be providing a
>    parser for E written in JavaScript, perhaps by way of OMeta.)

Perhaps, though I am loath to impose extra work on you or anyone. :)

> 3. Would revising the test suite such that, while still using the Updoc
>    syntax for tests, the test code itself is Cajita, suffice?

Perhaps. That would require an Updoc-Cajita, which is why I suggested
Mike Samuel's JSDoc as a possible tool.

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

On Oct 11, 2009, at 23:26, ihab.awad@... wrote:
> On Sun, Oct 11, 2009 at 7:50 PM, Kevin Reid <kpreid@...> wrote:
>> 1. Why do you wish to remove these dependencies?
>
> The main reason behind all these is to make Caja-CapTP easy to
> integrate into Cajita projects. This was intended as a contribution to
> further developing Caja-CapTP rather than a change of direction.

Point: The *tests* currently require E support; the library itself  
does not.

> Speaking for myself, I am not ready to hack the core implementation or
> the semantics of the tests. That said, my first step when trying to
> learn a library is to look at the tests and use them as a set of
> "worked examples" for how to use the library. In this case, the
> "worked examples" were not in the language and runtime environment
> that I was going to use for my finished product. So I took it upon
> myself to rewrite the tests in terms of that environment, and so
> hopefully to learn the library some more in the process.
>
> I understand the need to have non-duplication of the tests. Perhaps
> what we need may be comprehensive tests in E, and some "spot tests" /
> "worked examples" in Cajita. I honestly don't know what the right
> answer is at this point.

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

...Well, if you're looking just at the *serialization* system, not  
CapTP then it is true that there are tests at the level a user would  
work at; the serialization system is much less 'opaque' and more  
'here's some components, put them together how you like'.

>> 2. Would removing E-on-JavaScript's dependency on E-on-Java, such  
>> that
>>    it was a pure-JS or possibly even pure-Cajita (maybe with some  
>> Java)
>>    system, suffice? (The necessary work here would be providing a
>>   parser for E written in JavaScript, perhaps by way of OMeta.)
>
> Perhaps, though I am loath to impose extra work on you or anyone. :)

Well, that's a to-do item for EoJS anyway. The question is whether it  
supports your goals as well.

>> 3. Would revising the test suite such that, while still using the  
>> Updoc
>>    syntax for tests, the test code itself is Cajita, suffice?
>
> Perhaps. That would require an Updoc-Cajita, which is why I suggested
> Mike Samuel's JSDoc as a possible tool.

Based on a Google search I just looked at http://
jsdoc.sourceforge.net/ and http://code.google.com/p/jsdoc-toolkit/ and  
JSDoc seems to be a Javadoc-style tool, with no testing functionality.  
What am I missing?

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




_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[ihab.awad]

Hi Kevin,

[ + google-caja-discuss +mikesamuel ]

On Mon, Oct 12, 2009 at 4:24 AM, Kevin Reid <kpreid@...> wrote:
> Point: The *tests* currently require E support; the library itself
> does not.

Got it.

> These 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?

So anyway -- there ought to be an example, in Cajita, of setting up
vats A and B talking to each other. Mike Stay and I were merely trying
to do this the hard way -- by working through the code bottom-up. If
you are willing to do it for us the easy way, we would be delighted.
:)

> Based on a Google search I just looked at http://
> jsdoc.sourceforge.net/ and http://code.google.com/p/jsdoc-toolkit/ and
> JSDoc seems to be a Javadoc-style tool, with no testing functionality.
> What am I missing?

You are missing this:

  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.

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

On Oct 14, 2009, at 0:29, ihab.awad@... wrote:

> On Mon, Oct 12, 2009 at 4:24 AM, Kevin Reid <kpreid@...> 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/>




_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang