« Return to Thread: debugging interfaces
Re: debugging interfaces
by Jordan Osete-2
::
Rate this Message:
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
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
>> 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.
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
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
« Return to Thread: debugging interfaces
| Free embeddable forum powered by Nabble | Forum Help |
