Re: Various E patches

On Apr 13, 2010, at 11:17, Thomas Leonard wrote:

> On the other hand, it seems a bit silly to split out 118 lines of code
> into a separate module,

True. On the other hand, we might expect it to grow into a general 'E- 
style database API mapped to JDBC'.

> and access to a database is pretty vital for
> most applications, I would have thought (though I don't know what  
> other
> things E is being used for). Anything that needs persistence with
> reasonable performance is likely to need it, at least.

I think that what you consider “most applications” is almost  
completely different from my own experience, but that says more about  
us than any technical question.

> My two main concerns are:
>
> * Having some "official" SQL API, so people don't write their own
> because they didn't find the existing one (e.g. as happened with the
> module system).

This is a good point. In particular, since Java has an official SQL  
API, E-on-Java should include appropriate wrappers for it. I retract  
my objection on these grounds.

Have you fixed the synchronous access/determinism issues I previously  
mentioned in
   <http://www.eros-os.org/pipermail/e-lang/2010-March/013486.html>
?

>>> * Share a single SafeScope within each vat
>>
>> This sounds like the right thing. Where is it stored?
>
> Each ImportLoader creates and stores one (since there's already one
> ImportLoader per thread, and it's the thing that uses it).

Sounds reasonable. I'd like to take a closer look at it for  
inappropriate dependencies, though. Unless MarkM can get to it sooner.

>>> * In "not synchronously callable" error, give the verb
>>
>> E-on-CL generates "not synchronously callable: rec.verb(args...)" for
>> the message. The implementations shouldn't be gratuitously different
>> in this regard. Do you have a rationale for not printing the other
>> components?
>
> Just the general issue of error messages leaking information. I'm a  
> bit
> concerned about ex.eStack() showing the arguments too, though it's
> certainly useful.

eStack has enough information that you're utterly doomed.

Unfortunately there isn't a design issue page for it on the wiki, but  
the solution is that *every* throw()n exception object, or  
equivalently exception object you get from a catch block, is sealed.

Besides the debugging information, the throw-catch itself is  
*dynamically scoped* and therefore does not follow capability  
semantics; so we seal the information so that the only information a  
catch give is 'unexpected failure within'.

Only that with debugging access can see either the message or the  
eStack. Of course the REPL will automatically do that.

E-on-CL contains a partial implementation of these semantics.  
Unfortunately, there's no formal writeup of the whole thing that I  
know of, but there's some discussion in the mailing list archives.

http://www.google.com/search?q=site:eros-os.org+sealed+exceptions

If you'd like to help implement these semantics, please do -- it's one  
of the big security problems currently in E-on-Java for untrusted-code  
purposes, and one of the things that needs additional design work and  
experience with Real Applications which need to do things like logging  
errors.

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