Re: Next steps for Caja-CapTP

On Oct 11, 2009, at 23:26, [email protected] wrote:
> On Sun, Oct 11, 2009 at 7:50 PM, Kevin Reid <[email protected]> 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/>