Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322861

Summary:

Rhino StackFame should do a better job of serializing properties

Product:

[WebTools] JSDT

Reporter:

Michael Rennie <Michael_Rennie>

Component:

Debug

Assignee:

Michael Rennie <Michael_Rennie>

Status:

ASSIGNED ---

QA Contact:

Simon Kaegi <simon_kaegi>

Severity:

major

Priority:

CC:

thatnitind

Version:

3.2.1

Target Milestone:

Future

Hardware:

All

OS:

All

Whiteboard:

Bug Depends on:

Bug Blocks:

312287

Attachments:

Description	Flags
temp fix	none

Description Michael Rennie

2010-08-16 23:24:36 EDT

code from HEAD

Currently when we initialize the properties on the RhinoDebugger side of things we do so as a flat list of properties - combining the properties from the current Context with those from the global / prototype Contexts. 

We should better cache these properties so that we can show them in the variable view more sanely - instead of one huge listing of all properties. We also need to serialize them better for clients to make sense of the scope of the properties.

Comment 1 Simon Kaegi

2010-08-16 23:31:22 EDT

Agree whole heartedly and this single issue is really holding us back as an efficient debugging tool. I'm totally sick of going through the hundred odd global variables to pick out the local variables I actually care about.

To me this one is so important we might even consider back-porting it.

Comment 2 Michael Rennie

2010-08-17 10:27:58 EDT

(In reply to comment #1)
> To me this one is so important we might even consider back-porting it.

Agreed. This makes debugging worthless.

I'm on it.

Comment 3 Michael Rennie

2010-08-26 11:18:53 EDT

I have been playing around with different ways of doing this, and here are my thoughts:

1. we could have the serialized variables contain more data about the scope they belong to, which would not change the overall layout of the of the lookup packet payload - would go from: 
     {properties: {{ref:#,name:"name"}, etc}} to 
     {properties: {{ref:#,name:"name",scope:[closure | local]}, etc}}
The advantage of this is that any consumers using RDWP would not be broken and the variable sorting can be pluggable in the front end.

The disadvantage of this is the additional repeated wordage in the packet and possibly any additional logic needed on the front end.

2. we could order the serialized properties differently - would go from :
     {properties: {{ref:#,name:"name"}, etc}} to 
     {properties: {{closure:{ref:#,name:"name"}, etc}},local:{...}}

The advantage of this is less repeated wordage and a rather simple re-grouping

The disadvantage is it breaks any existing consumers.

3. we could leave the serialization the way it is and change the lookup request to take an optional parameter that would allow us to ask for only local or closure variables, this way if no-one ever expands the 'this' variable we don't send all that data over the wire. The re-grouping can be completely up to the debugger side of things.

Simon, Nitin, anyone, have any thoughts?

Comment 4 Michael Rennie

2010-08-26 13:45:23 EDT

Created attachment 177547 [details]
temp fix

This patch does not make any of the three aforementioned changes, instead it prevents the non-enumerable properties from being sent over the wire and only sends the parental ones is the activation context is the 'this' context.