Re: debugging interfaces

(Sorry for the late answer. Other stuff got this thread out of my mind.)

I understand that specifying a complete stratified API is necessary, however as it is still far from being ready yet, would it still be possible to implement something close to my first proposal (minus the offending parts) ?
As it stays quite simplistic (and only requires defining a single function), it could be ready much earlier, and would be a convenient replacement for the time being, until a complete stratified API is ready.

Well, just in case, here is what I would change about it today:

----------------------------

Keep some kind of global getStackTrace() function to get an array of stack frames. Each stack frame object has a number of properties to provide information about the given stack frame. I had divided this proposal in sections:

To identify what script we are in ("Script identification" section):
- I would not remove anything from this section.
- Maybe add an evalSourceURL property to identify the source file name for "named evals" (with "hacks" like this one, if something like that is ever standardized: http://blog.getfirebug.com/2009/08/11/give-your-eval-a-name-with-sourceurl/).

To identify where in the script we are ("In-script localization"):
- I would keep this section as it is.

And about the environment:
- This is the offending part that needs rewriting, as it is the one to propose providing direct references to objects and functions in the running environment (thus violating the JS-closures encapsuiation mechanism).
- To avoid the direct references, while still providing most of the available information, those objects could be converted to a different representation of them, a representation which would not expose everything we want to keep safe.
For example, the implementation could transform the object to JSON and provide the JSON'ed representation (it would have to watch for circular references though). Or create something like a "structured clone" (http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#structured-clone), or anything of the sort.
- It would still not be perfect, as it would provide no information for things like circular references, nor functions, or native objects (both JSON and structured-cloning algorythms would have to ignore any of these). It would also not allow testing for strict equality between objects, etc.
However, it would still provide a bunch of useful information, hopefully enough for most use cases, while still keeping it simple.
Actually, I really like the idea of using JSON. It is something that already exists, is well known, well understood, human readable, and widely supported. As it is a string, it can also easily be sent to a server or stored somewhere for later inspection.
- So for example, if we use JSON representation, 3 properties would remain for this section: thisObj (the JSON-Representation of the this object in the given stack frame), arguments (JSON-R of the arguments object), and variables (key-value  pairs containing information about every variable accessible in the stack frame). The function object currently executed can not be represented.

I hope this makes the proposal more acceptable. It can of course still be improved or extended.

Regards,

Jordan OSETE


Mark S. Miller a écrit :

On Tue, Jun 16, 2009 at 7:18 AM, Jordan Osete <jor@...> wrote:

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__,

Yes, JavaScript is already pervasively reflective in a non-stratified way. However, none of these violate the encapsulation of the one and only encapsulation mechanism present in EcmaScript -- functions evaluating to lexical closure that capture the variables in their scope. All the new reflective operators introduced by ES5 were careful to respect this boundary as well. De-facto JavaScript does have further reflective operators that do violate encapsulation -- <function-instance>.caller, <function-instance>.arguments, arguments.caller, and arguments.callee. ES5 specifies that these be disabled for strict functions so that the encapsulation of strict functions remains defensible.
 

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

This does violate information encapsulation and so does threaten confidentiality. However, it provides no access and so does not threaten integrity.
 

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 ?

Not by itself, no.
 

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.

 

Will take a look. Thanks for the pointer.

--
   Cheers,
   --MarkM

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss