debugging interfaces

Jordan Osete jor at joozt.net
Wed Aug 12 15:33:23 PDT 2009


(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 at joozt.net 
> <mailto:jor at joozt.net>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090813/2fd6cafb/attachment.html>


More information about the es-discuss mailing list