[Webkit-unassigned] [Bug 25419] InspectorController refactoring proposal

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=25419





------- Comment #7 from pfeldman at chromium.org  2009-04-30 12:05 PDT -------
(In reply to comment #6)
> (In reply to comment #5)
> > Ok, sure, let us start with step 1 and see how it goes. Actually, step 2
> > without migrating to Values is pretty much a noop. It would be great if 20031
> > addressed it, but as I understand, it is going to be resolved in JSC terms.
> > Hence we would still need to find a platform (JS core)-independent
> > serialization engine.
> > 
> > We could try doing it from within JS: InspectorController receives a network
> > event (didReceiveResponse), it passes it into javascript for serialization by
> > means of Scrip* objects, javascript code serializes message. Quite an
> > indirection, but no code duplication in the JSON serialization area. Also could
> > have some performance implications. Do you think it is better than pulling
> > Value/JSONReader/JSONWriter in? I think I can run some experiments on it.
> 
> We don't want two separate JSON implementations in WebKit. Bug 20031 is adding
> one to JSC, where it belongs. We don't want a seperate one up in WebCore just
> for the Inspector. What we could do is have JSON bridging classes like the
> Script classes Dimitri has added. So the Inspector can work with V8 or JSC's
> JSON parser/writer without tons of #ifdefs.
> 

Ok, I did not realize that ScriptObject is that mature already. Here is the new
plan then:

- I am substituting Value with ScriptObject in the design doc
- ScriptObject gets "String ScriptObject::stringify" and a factory "parse"
method.
- Both WebKit and Chromium use native JSON serialization behind the scenes.

Does this sound good to you?


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.