debugging interfaces

Jordan Osete jor at joozt.net
Tue Jun 16 07:18:48 PDT 2009


Mark S. Miller wrote:
>> Note: unfortunately, I do not "speak" Java at all, and thus I don't 
>> know JVM TI. I only skimmed through "JavaTM Virtual Machine Tool 
>> Interface (JVM TI)" 
>> (http://java.sun.com/javase/6/docs/technotes/guides/jvmti/), but it 
>> seems it goes far beyond what I describe here.
> It does indeed. I do not suggest that a debugging API be modeled on it 
> in any detail. However, it does have one great virtue: it is 
> stratified in the sense explained by <http://bracha.org/mirrors.pdf> 
> and not generally accessible from within the computation being 
> reflected upon. This is essential to reconcile debuggability with 
> strong encapsulation.
After a quick look into this PDF (very instructive, thanks), I think I 
understand the advantages of having a mirror API that is clearly 
distinct from the rest of the ES API.
However, ES already has a number of reflection features built in, that 
are clearly not stratified. From the prototype and constructor property, 
for...in statements that allow to list properties, typeof, instanceof, 
including new ones like the functions to __define / __lookup a Getter__ 
/ Setter__, including the actual stack traces API (like the Mozilla 
Stack object 
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Error/stack).

Also, there are a variety of environments a JS "thread" can run in 
today. For browsers, it may run in an HTML page, or in a Web worker, but 
it may also run in a command-line interpreter, and even as a server-side 
language. Will all those need different ways to get JS threads for 
examination ?

As for the browser, for example (sorry, it is by far the environment I 
am most familiar with), I think it would be nice to still allow a page 
to access this mirror API to "explore" another page, without needing 
explicit user consent under certain conditions (like a same-origin 
policy for the inspector / inspected page, for example). Test suites 
come to mind.
Would this kind of things be acceptable, from a security point of view ?

It *seems* Opera Dragonfly is using some kind of "Scope" thing as its 
mirror / proxy API 
(http://dev.opera.com/articles/view/opera-dragonfly-architecture/), and 
then the rest is pure web (Opera developers' insight would be welcome on 
that matter).
However (still about the browser), even the proxy part can be moved to 
pure web technologies (like XHR, through some server), in a debugging 
lib. That would leave only the mirror API to define in the standard.

Regards,

Jordan OSETE



More information about the es-discuss mailing list