Subj : Re: Serializing Object Graphs To : netscape.public.mozilla.jseng From : Eric Brueggemann Date : Wed Apr 09 2003 02:24 am Brendan Eich wrote: > > Why do you want this, exactly? > > Serialization at the native object level requires cooperation by the > native object's class or object-ops implementation (wherefore > JSClass.xdrObject and JSObjectOps.xdrObject). But many classes do not > fully implement these hooks. I doubt it's worth the effort trying to > get all the native ones, just in the core engine, to do so. Then there > are all the DOM ones. > > Invertible/transactional logging sounds better to me. But you'd still > need to record all changes at a low level. Again, is it worth the high > cost of implementation effort, and likely high cost in dynamic memory, > and medium to low cost in code footprint? > > /be > So for the logging approach, here's what I'm thinking: 1. Create an API to mark a rollback point and rollback to that point 2. Trap a change and store away the old value (only need to keep the oldest value for a given rollback point) and the type of change (add, modify, delete) 3. Have the GC treat stored values as roots (So that we can safely rollback even if the object being reference would normally have been a GC candidate.) 4. Upon rollback, restore the oldest values into the object's slot. Areas that I'm unsure of: 1. How do I save/restore properties that are being deleted. Looks like I'll need to save a few fields from JSScopeProperty: id, getter, setter, attrs, flags, and shortid. If I grab a free slot using js_AllocSlot, I should be able to use that id and add the property back using js_AddScopeProperty. Is there anything else going on that I'd need to keep track of? 2. What are the internal calls that I should be wrapping to do my logging? Is there a single call through which every add, set, and delete propery operation runs? Cheers, Eric .